Bug 369305

Summary: Color picking alternate invocation gets stuck when un-focusing the Krita window
Product: [Applications] krita Reporter: Phoenix Enero <phoenix.enero>
Component: Tablets (tablet issues are only very rarely bugs in Krita!)Assignee: Krita Bugs <krita-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: dimula73, halla
Priority: NOR    
Version: git master (please specify the git hash!)   
Target Milestone: ---   
Platform: Compiled Sources   
OS: All   
Latest Commit: https://commits.kde.org/krita/24479fd31531a5107f49c258473620db89b3eb94 Version Fixed In:
Sentry Crash Report:

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