Regression since 5.0.2 on master in integration with KDE plasma desktop (kwin). After changing virtual desktops in plasma using keyboard shortcuts with 'alt' modifier, none of the canvas inputs are recognized (color sampler, zooming and panning). Painting and usual shortcuts work properly. Only workaround to regain control over canvas inputs is to click on the layers docker area (only the widget where layers are displayed, no other region in dockers seem to work) STEPS TO REPRODUCE 1. On kubuntu 20.04 (though I hope it's recreatable with other KDE distros) assign global shortcut to kwin to any of the actions that change the desktop, so that it uses alt modifier. (move to the left/right desktop, move to desktop 1...) 2. Use this shortcut to move to desktop with krita window. 3. Try using any of the canvas inputs. Regain control by clicking on the layers docker. SOFTWARE/OS VERSIONS Operating System: Kubuntu 20.04 KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 Kernel Version: 5.4.0-104-generic OS Type: 64-bit ADDITIONAL INFORMATION I noticed this behaviour as I use ubuntu compatibile shortcuts (ctrl+alt+arrows) and use virtual desktops a lot. When I started triaging I noticed it's not so easy to recreate, as it requires custom shortcuts in kde. So I guess it's minor, non-blocking regression, and I may need to learn default kde shortcuts :) Still filing a bug report as this does not happen in 5.0.2. I believe deif_lou was changing something with modifiers to get freehand selection modes working. Could this be related, or there were other changes there?
I can confirm the issue, though I doubt it's related to deif_lou's work. This is more likely, since it's not in 5.0.2 (but it is in the krita/5.0 branch): commit 58392a1f9ae446da3f48c632f2bfe68d10a60ee4 Au58392a1f9ae446da3f48c632f2bfe68d10a60ee4thor: Dmitry Kazakov <dimula73@gmail.com> Date: Sat Jan 8 17:18:02 2022 +0300 Fix Krita forgetting about pressed keys when tapping Ctrl too quickly Under some circumstances, KeyPress/KeyRelease event comes **after** a tablet move event with already updated state. It is not very clear how that happens, but it is surely not impossible. Qt fills modifiers event property by reading some global storage, so it is possible that this state is not entirely in sync with the events queue. The patch does two fixes: 1) KisShortcutMatcher::recoveryModifiersWithoutFocus() used RecursionNotifier incorrectly, causing keyReleased() and keyPressed() to reset the state.
It seems to be fixed thanks to Dmitry's patch in bug 428080 Have tested with Super+D and Ctrl+Alt+arrows in Plasma, can't reproduce anymore on my end. (test with krita-5.2.0-prealpha-7ec45e4d3c)
(In reply to Protoniv from comment #2) > It seems to be fixed thanks to Dmitry's patch in bug 428080 > Have tested with Super+D and Ctrl+Alt+arrows in Plasma, can't reproduce > anymore on my end. (test with krita-5.2.0-prealpha-7ec45e4d3c) Still have focus issue with "windows key+D" on Windows though.
TL;DR: I fixed some issues that still remained open here, and what I have now looks good to me on Windows. The issues in question: On Windows, shortcuts like [Windows Key]+D and [Windows Key]+[0~9] still break canvas input due to keys that register as pressed but never released. The root cause is that krita uses both QT key events, and native Windows/X11 API "polling" calls. This creates situations where keys are polled and saved to KisShortcutMatcher's state, but no matching keyReleased events are generated. Blame may or may not be shared beween the parties, Windows, QT and krita. The solution proved tricky (to me), because I wanted to preserve the behaviour of krita wherein it still matches shortcuts while the application has no focus. Making changes to the affected code is very prone to breaking things in subtle and horrible ways, and I have not made it prettier. Perhaps there are better solutions. I will keep thinking on it. In essence, I tracked keys that were thus polled from native API calls, and re-querry these keys until they are released. Performance impact on systems that run Krita fluidly should be minimal, but it is an additional API call that occurs on every input, until all such keys have been cleared. I will test that i didnt break anything on linux later, though help would be appreciated. I cannot test OSX, though I suspect that some of the functionality described here never worked on OSX to begin with. My steps for testing everything is okay: 1) In the canvas input settings, bind canvas zoom to both: -shift + middle mouse button -0 (zero) + left mouse button 2) Focus and unfocus the application with clicking outside of it and back inside of it. Confirm both input methods still work. 3) Focus and unfocus the application with 2x alt+tab (or equivalent window manager hotkey). Confirm both input methods still work. 4) mix 2) and 3) 5) Focus and unfocus the application with 2x win+d (or equivalent window manager hotkey to minimize/maximize all applications). Confirm both input methods still work. 6) Unfocus the application, hold down shift, then mouse over the application and begin dragging the mouse. Confirm zoom begins immediately. 7) Unfocus the application, hold down 0 (Zero), then mouse over the application and begin dragging the mouse. Confirm zoom begins immediately. 8) (window manager specific) Focus Krita, then hit [Meta]+D twice. Confirm both input methods still work. 9) (windows only, may require specific settings) on the task bar, arrange things so that krita is the first application in the list, and another running application is second. Focus krita. Press [Windows Key]+2 followed by [Windows Key]+1. Krita should have focus again. Confirm both input methods still work. Its possible this obsoletes some other special cases, but the ones I looked at were still required as best as I could tell. https://invent.kde.org/simonra/krita/-/commit/381f23f9b25b5539fb910275cab0a1a265bb3991
Probably fixed by https://invent.kde.org/graphics/krita/-/merge_requests/1935, if this bug is still relevant, don't hesitate to reopen this bug.