Hi, If Krita during a paint session loose focus ( ex : typing on Irc, browsing web ) and user comeback to Krita to paint and want to Control+Click to pick a color, two minor weird things happen : 1) a dot is created on the canvas ( paint action ) Krita doesn't get the 'control' modifier, so it doesn't trigger the color picker 2) even if a dot is painted, Krita doesn't steal the focus, so you can press control+click and it will paint without stealing focus. In case you do a shortcut on keyboard, the previous apps will receive it. This is annoying on dual screen setup. On Gnome 3.10 here, focus policies is set to something like 'click to get focus'.
Hi, David! Do you have an ability to check whether this bug is reproducible on KDE? Or I need to install Gnome to reproduce that? I did a quick test on my KDE and is seemed to work fine :(
Hi Dmitry ! Oh, don't risk to install all the Gnome on your system to keep it clean. Here I have an hybrid Gnome-Kde ; so yes, I can switch. I could test. On KDE ( default setting ) the bug doesn't happen similar , very minor and certainly what I get used in the past : 1. On same screen ( don't overlap windows ) , with Krita left, and kate or gedit on right 2. Write a little text on the text editor 3. Take stylus fly hover Krita ( outline appear , focus not stealed , that's ok ) 4. Hold control and click with stylus 5. Not a color picker action happen, but a paint dot 6. Krita, after the dot get painted, get focus. 7. User can press Ctrl again+click , it will perform a color pick. On Gnome ( default ) the bug do this under same conditions : 1. to 5. is similar than on KDE , then 6. Krita, after the dot get painted, still don't get focus 7. User can press Ctrl again+click , it will perform another painted dot on canvas, without stealing focus. And it can be repeated 8. If a simple paint ( click ) action is done, Krita steal focus. So, probably Gnome specific , but I wondered if it wasn't an issue in how ctrl+click steal focus.
Ok, I've managed to replicate the KDE issue
Nice to know the KDE part is reproductible. I also add here the link of (old) bug 313499 "File drag-n-drop on canvas dialog , doesn't steal focus to Krita" ( fixed first, I reopened this morning ) a regression I'm suspecting to be back roughly in the same time than the one for the color-picker. Might help.
Git commit 46dcf385df2be83d57158587dd791005fec4991c by Dmitry Kazakov. Committed on 09/12/2013 at 10:52. Pushed by dkazakov into branch 'master'. Repopulate the state of the Input Manager when Krita gets the keyboard focus Krita can get the focus even when the user is already holding some key pressed (e.g. Control). In such a case, clicking with the mouse button will start painting instead of color picking, which might be a bit of surprising for a user. Theoretically, we can steal focus on mouse enter, but this may be inconvenient for a user in a bunch of usecases. M +1 -0 krita/ui/CMakeLists.txt A +170 -0 krita/ui/input/kis_extended_modifiers_mapper.cpp [License: GPL (v2+)] A +43 -0 krita/ui/input/kis_extended_modifiers_mapper.h [License: GPL (v2+)] M +13 -0 krita/ui/input/kis_input_manager.cpp http://commits.kde.org/calligra/46dcf385df2be83d57158587dd791005fec4991c
Git commit b07db9a055f3aad073a375c00cefc27052889e59 by Dmitry Kazakov. Committed on 09/12/2013 at 10:52. Pushed by dkazakov into branch 'calligra/2.8'. Repopulate the state of the Input Manager when Krita gets the keyboard focus Krita can get the focus even when the user is already holding some key pressed (e.g. Control). In such a case, clicking with the mouse button will start painting instead of color picking, which might be a bit of surprising for a user. Theoretically, we can steal focus on mouse enter, but this may be inconvenient for a user in a bunch of usecases. M +1 -0 krita/ui/CMakeLists.txt A +170 -0 krita/ui/input/kis_extended_modifiers_mapper.cpp [License: GPL (v2+)] A +43 -0 krita/ui/input/kis_extended_modifiers_mapper.h [License: GPL (v2+)] M +13 -0 krita/ui/input/kis_input_manager.cpp http://commits.kde.org/calligra/b07db9a055f3aad073a375c00cefc27052889e59
*Additional infos , specific to Gnome desktop :* Gnome 3.10 and above got a particuliar context : Ctrl+click can't steal focus , it's a feature of the Gnome windows manager : to select text of a subwindow ( while holding Ctrl ) without stealing focus. This is not a documented feature, but as the whole desktop work this way, this is a guess I made. That's why I understand it's not a workaround to do on the side of the Krita project. I'll report the "focus steal problem" on Gnome bugzilla soon.