Bug 459384

Summary:	Fire shortcuts on key release, not press
Product:	[Frameworks and Libraries] frameworks-kglobalaccel	Reporter:	owl-from-hogvarts
Component:	general	Assignee:	kdelibs bugs <kdelibs-bugs-null>
Status:	RESOLVED DUPLICATE
Severity:	wishlist	CC:	nate
Priority:	NOR
Version First Reported In:	5.97.0
Target Milestone:	---
Platform:	Manjaro
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

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 ***