| Summary: | Window filtering conditions for custom shortcuts (usually) don't work | ||
|---|---|---|---|
| Product: | [Applications] systemsettings | Reporter: | Adam Fontenot <adam.m.fontenot+kde> |
| Component: | kcm_khotkeys | Assignee: | Michael Jansen <kde> |
| Status: | RESOLVED UNMAINTAINED | ||
| Severity: | normal | CC: | dag, plasma-bugs-null |
| Priority: | NOR | ||
| Version First Reported In: | 5.23.2 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | test khotkeys group | ||
|
Description
Adam Fontenot
2021-10-28 11:53:13 UTC
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. |