Bug 420493

Cannot reproduce; If I hit Meta+L to lock the screen, for example, it locks on press, not release.

What is your use cases? I'm having a hard time understanding what the problem is.

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

Meta+l works for me too. Did you reproduce exactly as reported? I.e. add a new (e.g. Meta+k) shortcut from the systemsettings gui to trigger an action (e.g. xrandr dpms force off).

Is this working for you? Are you on my same version?

*** Bug 459384 has been marked as a duplicate of this bug. ***

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 


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

*** Bug 476353 has been marked as a duplicate of this bug. ***

I've tested Andrey suggestion from https://bugs.kde.org/show_bug.cgi?id=453506#c3
Since Plasma 5.8 we can bind "Modifier-only" KWin shortcut (for now it could be "Meta", "Alt", "Shift" and "Control", according to the https://invent.kde.org/plasma/kwin/-/blob/Plasma/5.27/autotests/integration/modifier_only_shortcut_test.cpp) which triggers action on release (not press).
So I assigned "Shift" to the qdbus command to switch the keyboard layout

kwriteconfig5 --file kwinrc --group 'ModifierOnlyShortcuts' --key 'Shift' 'org.kde.keyboard,/Layouts,org.kde.KeyboardLayouts,switchToNextLayout'
qdbus org.kde.KWin /KWin reconfigure

Looks like this is the way! Now I can switch keyboard layouts with a single "Shift" press. But when I use combinations involving "Shift", the keyboard layout doesn't change and combinations seem to work properly. E.g., I can type capital letters and other symbols, use Ctrl+Shift+V paste on a terminal emulator, etc.

(In reply to Yevhen from comment #7)
> I've tested Andrey suggestion from
> https://bugs.kde.org/show_bug.cgi?id=453506#c3
> Since Plasma 5.8 we can bind "Modifier-only" KWin shortcut (for now it could
> be "Meta", "Alt", "Shift" and "Control", according to the
> https://invent.kde.org/plasma/kwin/-/blob/Plasma/5.27/autotests/integration/
> modifier_only_shortcut_test.cpp) which triggers action on release (not
> press).
> So I assigned "Shift" to the qdbus command to switch the keyboard layout
> 
> kwriteconfig5 --file kwinrc --group 'ModifierOnlyShortcuts' --key 'Shift'
> 'org.kde.keyboard,/Layouts,org.kde.KeyboardLayouts,switchToNextLayout'
> qdbus org.kde.KWin /KWin reconfigure
> 
> Looks like this is the way! Now I can switch keyboard layouts with a single
> "Shift" press. But when I use combinations involving "Shift", the keyboard
> layout doesn't change and combinations seem to work properly. E.g., I can
> type capital letters and other symbols, use Ctrl+Shift+V paste on a terminal
> emulator, etc.

P.S. qbbus method call for "Alternative shortcut" (which supports "OSD on layout change" on both Wayland and X11) works as well:
kwriteconfig5 --file kwinrc --group 'ModifierOnlyShortcuts' --key 'Shift' 'org.kde.kglobalaccel,/component/KDE_Keyboard_Layout_Switcher,org.kde.kglobalaccel.Component,invokeShortcut,Switch to Next Keyboard Layout'
qdbus org.kde.KWin /KWin reconfigure

Could someone help clarify what this bug report is about? I don't think I understand what is reported/requested here after reading all the comments.

Normal shortcuts trigger on press, and we are not going to change that. If the bug report is about that, this should be closed as INTENTIONAL.

Modifier-only shortcuts trigger on release. Modifier-only shortcuts assigned through system settings (not through kwin) is fixed by https://invent.kde.org/plasma/kglobalacceld/-/merge_requests/44. Is there anything left to be done here?

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!