Bug 372646 - Unable to pan after picking color from reference image until canvas is clicked once first
Summary: Unable to pan after picking color from reference image until canvas is clicke...
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Tools (show other bugs)
Version: 3.1 Beta
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Dmitry Kazakov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-11-18 21:00 UTC by Andy Statia
Modified: 2020-05-19 09:08 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andy Statia 2016-11-18 21:00:13 UTC
When using the reference image docker to pick a colour, it is not possible to immediately pan using the pan shortcut (typically spacebar).  The tool icon still shows the last active tool, such as fill or brush, despite the pan shortcut being pressed.  One must first click somewhere outside the reference image before the tool will switch to the pan tool.
Comment 1 Andy Statia 2016-11-18 21:05:23 UTC
This issue also appears to affect the colour picker (and probably any tool change prompted by a keyboard shortcut).
Comment 2 Alexey Putz 2016-11-19 14:52:56 UTC
Hello. 
I tried it and I didn't reproduce the bug.
I used Krita from page : 

https://krita.org/en/item/krita-3-1-beta-4-released/

Krita version 3.0.93

1. Opened an image.
2. Used the pick color tool, color was successfully picked.
3. Used pan shortcut (space), the icon of colorpicker was successfully changed to the icon of pan (hand).
4. Navigated with pan without need to click before pan.
5. Used ctrl+r shortcut, the icon changed successfully, selected a rectangular area.
6. Used Pan with shortcut space. 


Kubuntu 16.10
KDE Plasma Version : 5.7.5
KDE Frameworks Version : 5.26.0
Qt Version : 5.6.1
Kernel Version : 4.8.0-22-generic
OS Type: 64-bit
Comment 3 Andy Statia 2016-11-19 15:38:05 UTC
In your replication steps, I don't see where you opened a reference image to choose a colour from.  If I do the steps as noted by you, it also works for me.  The issue only arises if you pick a colour from the image in the reference image panel, not from the current document.


(In reply to Alexey Putz from comment #2)
> Hello. 
> I tried it and I didn't reproduce the bug.
> I used Krita from page : 
> 
> https://krita.org/en/item/krita-3-1-beta-4-released/
> 
> Krita version 3.0.93
> 
> 1. Opened an image.
> 2. Used the pick color tool, color was successfully picked.
> 3. Used pan shortcut (space), the icon of colorpicker was successfully
> changed to the icon of pan (hand).
> 4. Navigated with pan without need to click before pan.
> 5. Used ctrl+r shortcut, the icon changed successfully, selected a
> rectangular area.
> 6. Used Pan with shortcut space. 
> 
> 
> Kubuntu 16.10
> KDE Plasma Version : 5.7.5
> KDE Frameworks Version : 5.26.0
> Qt Version : 5.6.1
> Kernel Version : 4.8.0-22-generic
> OS Type: 64-bit
Comment 4 Alexey Putz 2016-11-19 16:20:14 UTC
Thanks for your comment, I was able to reproduce this bug. 

1. Open the reference image toolbar.(Settings - Dockers - Reference images)
2. Open an image at the toolbar.
3. Open an image in primary document window.
4. Use color picking tool at the reference image.
5. Quickly slide the cursor back on the primary document window image.
6. Bag occurs. While pressing hotkey for Pan the pan mode is not activated, the cursor stays in the color picking mode representation.


Note: If cursor slided very smooth over the bound between the reference image area and main document window the bug doesn't occur.



Krita version 3.0.93

Kubuntu 16.10
KDE Plasma Version : 5.7.5
KDE Frameworks Version : 5.26.0
Qt Version : 5.6.1
Kernel Version : 4.8.0-22-generic
OS Type: 64-bit
Comment 5 Andy Statia 2016-11-19 17:34:57 UTC
Awesome!  I recorded a video of the replication as well in case it is useful.

https://www.youtube.com/watch?v=pfk94vmyrK8
Comment 6 Andy Statia 2016-12-02 03:38:19 UTC
This issue seems to be much broader than just the reference docker.  Clicking on almost any UI element (tool buttons, layer docker items, etc.) prevents certain tool switching until you click the canvas once.  Tested by choosing different tools from the toolbar and trying to use pan, clicking a layer (Layers panel), or any setting in a panel.
Comment 7 Halla Rempt 2016-12-08 10:21:42 UTC
*** Bug 373299 has been marked as a duplicate of this bug. ***
Comment 8 Dmitry Kazakov 2016-12-12 10:40:20 UTC
Hi, Andy and Alexey!

As far as I can see, only cursor icon doesn't change when you move out of the docker. If you press space and start a drag (even thought the cursor is wrong) the panning action will start correctly. 

Could you check if you can start panning correctly?

If so, the report is still a bug, yes, but not a release blocker at least. And I will check what can be done there to update the icon correctly. As far as I remember, we wait for 1 or 2 seconds of hovering over the canvas and then start pre-activation of actions, which involve updating the cursor.
Comment 9 Andy Statia 2016-12-12 16:07:12 UTC
When doing this, I always end up drawing a line across my canvas instead of panning, which I have to undo quickly and then re-try the pan (which would then work since the canvas had been clicked).

So unfortunately, it's not just a matter of the cursor not updating.  I'm not sure I'd even have noticed it if that were the case.  As it is, I'm very frequently having to undo that stroke across my work received when trying to pan.
Comment 10 Joannes J 2018-04-03 13:56:57 UTC
What I'm observing is that clicking in certain dockers and then hovering over the canvas and not moving makes things like pan and zoom unavailable. I can wait as long as I want and press the spacebar all I want, it doesn't react. But if I do the same thing and instead of keeping my cursor still I wiggle it around for a second, then pan and zoom do work. 

So that 1-2 second wait Dmitry mentions might be related?
Comment 11 Halla Rempt 2018-04-03 14:14:14 UTC
Hm, the original report was about the reference docker, and that's removed now, so I wonder whether we couldn't just close this bug.
Comment 12 Joannes J 2018-04-03 17:25:12 UTC
Why not rename it? The bug is still there, it's just broader then originally perceived.
Comment 13 Halla Rempt 2020-04-10 09:03:23 UTC
Git commit 5438445da9651785585ea913c37293737a5ee608 by Boudewijn Rempt.
Committed on 10/04/2020 at 08:59.
Pushed by rempt into branch 'master'.

Set focus on the view on mouse-over

This "should" solve the issues we have when an widget in a docker
has input focus, and people move the cursor back to the canvas
and start to pan or paint.

However, it's a _very_ brute-force method, so we all need to be
aware of this change and check whether stupid things happen, in
which case we might need to do something a bit more subtle, with
timers or so...

CCMAIL:kimageshop@kde.org

M  +6    -0    libs/ui/KisView.cpp
M  +1    -0    libs/ui/KisView.h

https://invent.kde.org/kde/krita/commit/5438445da9651785585ea913c37293737a5ee608
Comment 14 Halla Rempt 2020-04-10 12:35:26 UTC
*** Bug 391088 has been marked as a duplicate of this bug. ***
Comment 15 Dmitry Kazakov 2020-04-15 20:52:51 UTC
Git commit d454a04e713c0ffc4167021680f69be3698871ec by Dmitry Kazakov.
Committed on 15/04/2020 at 20:46.
Pushed by dkazakov into branch 'krita/4.3'.

Fix pan/zoom shortcuts not working after accessing any docker

The reason for the bug was that KisExtendedModifiersMapper::
queryExtendedModifiers() has never been implemented for Windows.
Therefore all the shortcuts including Space could potentially be
lost when the user pressed it without focusing on the canvas.

We also need an implementation for OSX.
Related: bug 373299, bug 391088

M  +53   -3    libs/ui/input/kis_extended_modifiers_mapper.cpp

https://invent.kde.org/kde/krita/commit/d454a04e713c0ffc4167021680f69be3698871ec
Comment 16 Dmitry Kazakov 2020-04-15 20:53:01 UTC
Git commit f49dac3a603d8d40108523be436be1b251966ac5 by Dmitry Kazakov.
Committed on 15/04/2020 at 20:48.
Pushed by dkazakov into branch 'master'.

Fix pan/zoom shortcuts not working after accessing any docker

The reason for the bug was that KisExtendedModifiersMapper::
queryExtendedModifiers() has never been implemented for Windows.
Therefore all the shortcuts including Space could potentially be
lost when the user pressed it without focusing on the canvas.

We also need an implementation for OSX.
Related: bug 373299, bug 391088

M  +53   -3    libs/ui/input/kis_extended_modifiers_mapper.cpp

https://invent.kde.org/kde/krita/commit/f49dac3a603d8d40108523be436be1b251966ac5
Comment 17 vanyossi 2020-05-19 06:04:51 UTC
Git commit 4b9fa0c85e8f4cf9412ad01dd073c4a83ac7ea67 by Ivan Yossi.
Committed on 19/05/2020 at 06:04.
Pushed by ivany into branch 'master'.

fix extenderModifiers for OSX

Keys other than modifiers cannot be accessed outside
of non key related events from NSApplication. adding
a local monitor allows to catch the keys we need
during the delay duration.

Try to handle all modifiers from localMonitor

Apply modifiers already pressed on focusIn events macos

We now request a copy of keydown and modifier change
events to set the proper flags as background application
Related: bug 373299, bug 391088

M  +1    -0    libs/ui/CMakeLists.txt
M  +18   -0    libs/ui/input/kis_extended_modifiers_mapper.cpp
M  +5    -0    libs/ui/input/kis_extended_modifiers_mapper.h
C  +14   -26   libs/ui/input/kis_extended_modifiers_mapper_osx.h [from: libs/ui/input/kis_extended_modifiers_mapper.h - 051% similarity]
A  +134  -0    libs/ui/input/kis_extended_modifiers_mapper_osx.mm
M  +6    -0    libs/ui/input/kis_input_manager.cpp
M  +12   -0    libs/ui/input/kis_input_manager_p.cpp

https://invent.kde.org/graphics/krita/commit/4b9fa0c85e8f4cf9412ad01dd073c4a83ac7ea67
Comment 18 Halla Rempt 2020-05-19 09:08:55 UTC
Git commit 483d38ba26d4008a74c16f5f96c525ff997b618c by Boudewijn Rempt, on behalf of Ivan Yossi.
Committed on 19/05/2020 at 09:08.
Pushed by rempt into branch 'krita/4.3'.

fix extenderModifiers for OSX

Keys other than modifiers cannot be accessed outside
of non key related events from NSApplication. adding
a local monitor allows to catch the keys we need
during the delay duration.

Try to handle all modifiers from localMonitor

Apply modifiers already pressed on focusIn events macos

We now request a copy of keydown and modifier change
events to set the proper flags as background application
Related: bug 373299, bug 391088
(cherry picked from commit 4b9fa0c85e8f4cf9412ad01dd073c4a83ac7ea67)

M  +1    -0    libs/ui/CMakeLists.txt
M  +18   -0    libs/ui/input/kis_extended_modifiers_mapper.cpp
M  +5    -0    libs/ui/input/kis_extended_modifiers_mapper.h
C  +14   -26   libs/ui/input/kis_extended_modifiers_mapper_osx.h [from: libs/ui/input/kis_extended_modifiers_mapper.h - 051% similarity]
A  +134  -0    libs/ui/input/kis_extended_modifiers_mapper_osx.mm
M  +6    -0    libs/ui/input/kis_input_manager.cpp
M  +12   -0    libs/ui/input/kis_input_manager_p.cpp

https://invent.kde.org/graphics/krita/commit/483d38ba26d4008a74c16f5f96c525ff997b618c