Bug 369305 - Color picking alternate invocation gets stuck when un-focusing the Krita window
Summary: Color picking alternate invocation gets stuck when un-focusing the Krita window
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Tablets (tablet issues are only very rarely bugs in Krita!) (show other bugs)
Version: git master (please specify the git hash!)
Platform: Compiled Sources All
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-25 06:32 UTC by Phoenix Enero
Modified: 2019-04-18 10:11 UTC (History)
2 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 Phoenix Enero 2016-09-25 06:32:13 UTC
Activating any of the color picking alternate invocation (such as when holding the Control Key) then placing the Krita window out of focus keeps the activated invocation stuck.

Reproducible: Always

Steps to Reproduce:
Set Canvas Input Settings → Alternative Invocation to default. Keep the Krita program windowed (for convenience as you'll see later.)

1. Open any document or create a new one.
2. Place your cursor in the Krita canvas area.
3. Hold the control key. You should see a Foreground Color PIck.
4. While holding the control key, un-focus the Krita window by clicking anywhere that isn't the Krita window.
5. Release the control key.
6. Move the cursor back to the Krita canvas.

Actual Results:  
The Foreground Color PIck mode is still activated. Clicking the canvas will pick the color instead of placing a brush stroke.

Expected Results:  
The Foreground Color Pick mode is not activated. Clicking the canvas would place a brush stroke instead of picking the color.

Similar behavior is shown with the other Color Pick alternate invocations: Foreground Color Pick from Current Layer, Background Color Pick from Current Layer, Background Color Pick from Merged Layers.
Comment 1 Phoenix Enero 2016-09-25 06:36:08 UTC
Forgot to add: The tablet I'm using is HUION H610 Pro.
Comment 2 Dmitry Kazakov 2019-04-17 18:45:55 UTC
Hah, I still can reproduce the problem... even after my recent tablet support refactoring. Let's fix it soon :)
Comment 3 Dmitry Kazakov 2019-04-18 08:21:45 UTC
Okay, the problem is reproducible on both Linux and Windows on any kind of tablets.
Comment 4 Dmitry Kazakov 2019-04-18 10:11:41 UTC
Git commit 24479fd31531a5107f49c258473620db89b3eb94 by Dmitry Kazakov.
Committed on 18/04/2019 at 10:06.
Pushed by dkazakov into branch 'master'.

Workaround Krita canvas cursor update when application has no input focus

When we have no input focus, we cannot track keyboard key press/release
events (for security reasons). But at the same time, the user can easily
hover Krita canvas, and we should show him somewhat correct cursor.

So here we just try to fetch at least basic modifiers state from mouse/
tablet events. It is perfectly allowed by OS.

Yes, this workaround will not fetch custom modifiers like V-key switch
for straight lines. But I don't think anyone will worry about it.

M  +24   -1    libs/ui/input/kis_input_manager_p.cpp
M  +26   -0    libs/ui/input/kis_shortcut_matcher.cpp
M  +10   -0    libs/ui/input/kis_shortcut_matcher.h

https://commits.kde.org/krita/24479fd31531a5107f49c258473620db89b3eb94