https://bugs.kde.org/show_bug.cgi?id=451424
Simon Ra <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #4 from Simon Ra <[email protected]> --- 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 -- You are receiving this mail because: You are watching all bug changes.
