Bug 459384 - Fire shortcuts on key release, not press
Summary: Fire shortcuts on key release, not press
Status: RESOLVED DUPLICATE of bug 420493
Alias: None
Product: frameworks-kglobalaccel
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 5.97.0
Platform: Manjaro Linux
: NOR wishlist
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-09-19 11:05 UTC by owl-from-hogvarts
Modified: 2022-09-22 19:50 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description owl-from-hogvarts 2022-09-19 11:05:23 UTC
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
Comment 1 owl-from-hogvarts 2022-09-19 19:36:19 UTC
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
Comment 2 owl-from-hogvarts 2022-09-21 05:57:13 UTC
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!
Comment 3 Nate Graham 2022-09-22 19:50:51 UTC

*** This bug has been marked as a duplicate of bug 420493 ***