SUMMARY Currently custom keyboard shortcuts either exist and are active or they don't exist and are inactive. This is incredibly inconvenient on wayland, because custom keyboard shortcuts intercept the keycode and don't propagate it to the currently active application. Example: I have F10 as a custom keyboard shortcut for OBS to start recording using the OBS webhook because wayland is super secure and very good. Turns out I'm not wanting to record anything and I have OBS closed but want to use the F10 key to toggle some functionality in the Moonlight software, but oops: The global shortcut for F10 is still active so instead of sending the keycode for F10 to Moonlight KDE goes and starts my OBS record script, which does nothing because OBS is not running, but now I can't toggle the function in Moonlight that I wanted. To "disable" the keycode override I now have to delete the entire shortcut. And if I need the shortcut again at a later date I have to recreate it from scratch (or I have to keep a .txt file with a list of all shortcuts so that I can create them again). STEPS TO REPRODUCE 1. Create a custom keyboard shortcut 2. Observe that it stops the keycode from being sent to the focussed application 3. Try to disable the shortcut with a checkbox in the settings menu 4. Observe that there is no disable/enable checkbox OBSERVED RESULT There is no way to disable custom keyboard shortcuts without deleting them or removing the bound key EXPECTED RESULT In my opinion there should be a way to disable specific custom keyboard shortcuts without deleting them or removing the bound key. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.13.3-273-tkg-bore KDE Plasma Version: 6.3.1 KDE Frameworks Version: 6.11.0 Qt Version: 6.8.2 ADDITIONAL INFORMATION Sorry for the wall of text. Wayland is incredibly frustrating when xorg is not an option. Much love
If something has default shortcuts, those can be disabled rather than removed, yes. Non-default shortcuts can only be removed though. And for custom commands, since they by definition have no default shortcuts, they therefore inherit the "can only be deleted, not disabled" behavior. So I can see where the issue comes from with your use case. The thing is, if we did add the functionality you're requesting, surely the "this is a pain in the ass" behavior would simply shift to the annoyance of having to disable and re-enable the shortcut. It wouldn't actually stop being a pain in the ass, right? In general, since the shortcuts are global in scope, you want to avoid overlaps with apps' functionality. Generally that's accomplished by using modifier keys. In this case, maybe Meta+F10 would be a better shortcut? Is there a reason why that doesn't work for your use case?
(In reply to Nate Graham from comment #1) > If something has default shortcuts, those can be disabled rather than > removed, yes. Non-default shortcuts can only be removed though. And for > custom commands, since they by definition have no default shortcuts, they > therefore inherit the "can only be deleted, not disabled" behavior. So I can > see where the issue comes from with your use case. > > The thing is, if we did add the functionality you're requesting, surely the > "this is a pain in the ass" behavior would simply shift to the annoyance of > having to disable and re-enable the shortcut. It wouldn't actually stop > being a pain in the ass, right? > > In general, since the shortcuts are global in scope, you want to avoid > overlaps with apps' functionality. Generally that's accomplished by using > modifier keys. In this case, maybe Meta+F10 would be a better shortcut? Is > there a reason why that doesn't work for your use case? Hi Nate, thank you for your reply. Indeed, the pain in the ass behaviour would shift to the need for enabling and disabling custom shortcuts, but the underlying issue that keycodes are intercepted and not forwarded to the active application is as far as I understand a fundamental core part of waylands ̶d̶e̶g̶r̶a̶d̶a̶t̶i̶o̶n̶ ̶o̶f̶ ̶u̶s̶e̶r̶ ̶e̶x̶p̶e̶r̶i̶e̶n̶c̶e̶ security tenets, so that cannot be changed. It is still preferable (in my opinion) to be able to enable and disable custom shortcuts instead of having to keep track of custom shortcuts in a spreadsheet somewhere that is separate from the KDE settings. The reason why Meta+F10 does not work for my case is twofold: 1) It's probably already bound to some default shortcut like "Switch to Workspace 10" and 2) I have a 65% keyboard that doesn't have a function-key row. Not only do I not have a Meta button on the right side of my keyboard, I also need to hit the Layer+ key to turn my Number-Row into the function row, and suddenly a 2-button shortcut is turned into a 3-button shortcut not unlike the 3-finger salute, just even more uncomfortable. You are of course not obligated in any way to support custom keyboard layouts, this is just the reason why for me personally it doesn't work well.
Being able to disable a custom shortcut's keyboard shortcut (or maybe even the whole thing) makes sense, but I would still encourage you to seek out a different solution for your use case here, as even if we implement this, it sounds like the result will still be uncomfortable and annoying.
(In reply to Nate Graham from comment #3) > Being able to disable a custom shortcut's keyboard shortcut (or maybe even > the whole thing) makes sense, but I would still encourage you to seek out a > different solution for your use case here, as even if we implement this, it > sounds like the result will still be uncomfortable and annoying. Agreed. In most cases users just want to set or unset a shortcut, not disable/enable custom shortcuts. (In reply to insuna from comment #2) > (In reply to Nate Graham from comment #1) > > In this case, maybe Meta+F10 would be a better shortcut? Is > > there a reason why that doesn't work for your use case? > > The reason why Meta+F10 does not work for my case is twofold: 1) It's > probably already bound to some default shortcut like "Switch to Workspace > 10" and 2) I have a 65% keyboard that doesn't have a function-key row. Not > only do I not have a Meta button on the right side of my keyboard, I also > need to hit the Layer+ key to turn my Number-Row into the function row, and > suddenly a 2-button shortcut is turned into a 3-button shortcut not unlike > the 3-finger salute, just even more uncomfortable. kmonad[0] may be a useful tool for your circumstances. It allows you to use ordinary keys as modifiers when held (e.g., I configured my z,x,c, to also act as ctrl, meta, and alt respectively, and similarly on the right). If you are using a mechanical keyboard that supports QMK [1], that also provides this functionality (and more) at a firmware level. [0]: https://github.com/kmonad/kmonad [1]: https://github.com/qmk/qmk_firmware/tree/master
(In reply to Nate Graham from comment #3) > Being able to disable a custom shortcut's keyboard shortcut (or maybe even > the whole thing) makes sense, but I would still encourage you to seek out a > different solution for your use case here, as even if we implement this, it > sounds like the result will still be uncomfortable and annoying. Then if disabling custom shortcuts, which would greatly alleviate the pain, is not possible: Is it feasible to add an option for the kde compositor to replay intercepted keycodes/shortcuts into the focused application? Similar to how `xdotool` used to work?