SUMMARY This is potentially annoying to debug because it seems to rarely function just fine. It's just that usually, it doesn't. I'm happy to follow any debugging suggestions given, I can even recompile khotkeys if necessary. STEPS TO REPRODUCE 1. Create a new custom shortcuts group. 2. Set the action to be anything involving an active window. I set mine so that the window title has to contain "a". 3. Add a global shortcut that sends keyboard input to the group. Set the trigger to whatever you like, and the action to insert some arbitrary text. 4. Click in a window that matches the requirements you set in 2. OBSERVED RESULT The window behaves as if there was no shortcut. If I set the shortcut to Alt+O, for example, then "o" is printed in the textbox that has focus. If the program that owns the window has its own shortcuts, those execute instead of the global shortcut. EXPECTED RESULT The window does not receive the key events at all. Instead, whatever text was entered in step 3 is typed into the window instead. SOFTWARE/OS VERSIONS Linux: Arch Linux x86_64 (kernel 5.14.14) KDE Plasma Version: 5.23.2 KDE Frameworks Version: 5.87.0 Qt Version: 5.15.2 OTHER NOTES: Certain shortcuts triggers disappear when I close and reopen system settings. I assume that issue is https://bugs.kde.org/show_bug.cgi?id=300532 There seems no pattern to which shortcuts don't work - none of them, to my knowledge, is otherwise bound as a global shortcut.
Works for me. > 2. Set the action to be anything involving an active window. I set mine so that the window title has to contain "a". Please provide an exact config (*.khotkeys) instead of a loose description. (In meanwhile, I guess, that you are forgetting to select window type.)
Created attachment 143608 [details] test khotkeys group (In reply to Dmitry Alexandrov from comment #1) > Works for me. > > > 2. Set the action to be anything involving an active window. I set mine so that the window title has to contain "a". > > Please provide an exact config (*.khotkeys) instead of a loose description. > > (In meanwhile, I guess, that you are forgetting to select window type.) I was able to repro this with a shortcut group with a window type selected. Attached. Worth pointing out that I use a non-qwerty layout and that this issue might somehow be related to that. (There are *many* open bugs related to khotkeys handling of variant keyboard layouts.) That sounds like a really nasty bug, though. Surely if you don't select a window type the expected behavior would be to match all window types!
Adam Fontenot <adam.m.fontenot+kde@gmail.com> wrote: > I was able to repro this with a shortcut group with a window type selected. Attached. Hmm... I was about to write again that it works for me, when upon changing the trigger back and forth, it had stopped. So, yes, there is bug, namely: some state is accumulated, that is not reflected in in the UI. Workaround is to create a _new_ action, rather that edit an existing one. >> (In meanwhile, I guess, that you are forgetting to select window type.) > > That sounds like a really nasty bug, though. Surely if you don't select a window type the expected behavior would be to match all window types! Yes, I also think that it worth at least reporting.
(In reply to Dmitry Alexandrov from comment #3) >>> (In meanwhile, I guess, that you are forgetting to select window type.) >> That sounds like a really nasty bug, though. Surely if you don't select a >> window type the expected behavior would be to match all window types! > Yes, I also think that it worth at least reporting. I reported this. Here's a link for those who come across this and want to track that bug: https://bugs.kde.org/show_bug.cgi?id=445623
As announced in https://pointieststick.com/2023/07/26/what-we-plan-to-remove-in-plasma-6/ and https://community.kde.org/Plasma/Plasma_6#Removals, I'm afraid KHotKeys has reached end-of-life in Plasma 6. Accordingly, all bug reports and feature requests for it must be closed now. Most of what KHotKeys could do can already be done with the newer KGlobalAccel system in Plasma 6. A few features such as mouse gestures and triggering conditions based on changes to window states are not yet implemented in the new system. These will be added in the future if and when resources materialize for them, and/or when a kind soul submits patches to implement them! :) Meanwhile, the 3rd-party "Mouse Actions" app (https://github.com/jersou/mouse-actions) may be usable for implementing your own mouse gestures again. Thanks for your understanding, everyone.