459384 2022-09-19 11:05:23 +0000 Fire shortcuts on key release, not press 2022-09-22 19:50:51 +0000 1 1 3 Frameworks and Libraries frameworks-kglobalaccel general 5.97.0 Manjaro Linux RESOLVED DUPLICATE 420493 NOR wishlist --- 0 owl-from-hogvarts kdelibs-bugs-null nate 0 oldest_to_newest 2154189 0 owl-from-hogvarts 2022-09-19 11:05:23 +0000 SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** Global shortcuts should be fired on key release and not press. OBSERVED RESULT Shortcuts are fired on key press. Therefore the shortest shortcut is fired instead of a desired one. So we can't have overlapping shortcuts, i.e. which starts with same, multiple modifiers keys (ctrl + shift + ... will not work if we have ctrl + shift assigned to layout switch). DESIRED BEHAVIOR Shortcuts are fired on key release, so the desired shortcut is fired instead of shortest. POSSIBLE IMPLEMENTATION P_BUFFER - buffer of pressed keys S_BUFFER - buffer of suspended keys 1. Accumulate pressed keys in P_BUFFER 1.1 on keypress event add pressed key to P_BUFFER (works same for all buttons, so we would be able to start shortcut from any shortcut's keys) 2. on keyrelease event of any key contained in P_BUFFER, fire shortcut with all keys currently in P_BUFFER, including one that was released just before (that is because we won't delete it from P_BUFFER just after the key was released, but will wait for shortcut to fire and only then remove) Note: other (still pressed) keys are moved to suspending buffer S_BUFFER. That means that when other keys will be released they won't cause any undesired shortcuts. BUT when any new key is pressed, already pressed keys (i.e. contained in S_BUFFER) will be moved back to P_BUFFER. Key will be REMOVED (and not moved) from suspending buffer ONLY when released SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.25.5 (available in About System) Operating System: Manjaro Linux KDE Plasma Version: 5.25.5 KDE Frameworks Version: 5.97.0 Qt Version: 5.15.5 Kernel Version: 5.19.7-1-MANJARO (64-bit) Graphics Platform: Wayland ADDITIONAL INFORMATION 2154345 1 owl-from-hogvarts 2022-09-19 19:36:19 +0000 EXAMPLE Lets imagine that we have next shortcuts defined: ctrl + shift - switch keyboard layout ctrl + shift + t - open new terminal instance ctrl + shift + d - show desktop And user acts like this: "wants to show desktop and open terminal" 1. press "shift" 2. press "ctrl" 3. press "d" and release it (ctrl + shift are still pressed) 4. press "t" and release ctrl, shift, t in order 5. press ctrl, shift to switch keyboard layout 6. releases shift What happens according to the algorithm: 1. shift is added to P_BUFFER 2. ctrl is added to P_BUFFER 3. d is added to P_BUFFER 4. release event for "d" received 5. shortcut "show desktop" is fired 6. content of P_BUFFER is moved to S_BUFFER (i.e. ctrl, shift, d) 7. system detects that "d" is no longer pressed and removes it from S_BUFFER (so the content of S_BUFFER becomes "ctrl, shift") 8. press event for "t" received 9. ctrl, shift are moved back to P_BUFFER 10. "t" is added to P_BUFFER 11. "ctrl" release event received 12. open new terminal instance shortcut fired 13. content of P_BUFFER is moved to S_BUFFER (i.e. ctrl, shift, t) 14. system detects that "ctrl" is no longer pressed and removes it from S_BUFFER (so the content of S_BUFFER becomes "shift, t") 15. receives release events for "shift, t" 16. removes "shift, t" from S_BUFFER so it becomes empty 17. receives press events for "ctrl" and "shift" 18. adds them to the P_BUFFER 19. receives release event for "shift" 20. fire "switch keyboard layout" shortcut 2154846 2 owl-from-hogvarts 2022-09-21 05:57:13 +0000 Excuse me, but may be the severeness is "major" since this thing affects all shortcuts (including of foreign applications, such as VS code, chrome). So current shortcut behavior heavily breaks my UX, because shortcuts, which includes ctrl + shift + ... are not working! 2155409 3 nate 2022-09-22 19:50:51 +0000 *** This bug has been marked as a duplicate of bug 420493 ***