SUMMARY Sometimes active hotkeys do not have an effect in current environment context (e.g. window rule shortcut) if the targeted window is currently not open. If at the same time the cursor is placed inside a textarea, in this particular case the literal character of the hotkey (e.g. letter "k" in case of hotkey Meta+K) is written into the textarea. STEPS TO REPRODUCE 1. Define a window shortcut rule for dolphin "Meta+D" 2. Close all dolphin windows 3. Place cursor in textarea of choice 4. Press shortcut "Meta+D" OBSERVED RESULT Letter "D" is written into textarea if shortcut target is currently not available. EXPECTED RESULT If particular shortcut has a defined target, the textarea input should be ignored. SOFTWARE/OS VERSIONS KDE Plasma Version: 5.22.5
Questions: 1. Can you clarify that this is a shortcut to launch Dolphin? Or does it do something else? 2. How did you set this shortcut? Using the System Settings page named "Shortcuts" or "Custom Shortcuts" or KMenuEdit or some other means? 3. What exactly do you mean by "if shortcut target is currently not available"? Does this mean that your Meta+D shortcut only works if a Dolphin window is open?
The kind of shortcut has to be clarified as "window rule shortcut" which can be defined in System Settings/Window Rules. It enables the user to change window focus (towards a "target" window that matches the rule) by pressing a keyboard shortcut. But if none of the open windows matches any rule, plus the text cursor is placed inside a textfield/textarea, then the character part of the shortcut (e.g. Meta+K) is written into the textarea. This can lead to erroneous editing.
Additionally, if multiple "target" windows are open, the hypothetical shortcut Meta+K only focuses on the first window matching the rule (like described here https://bugs.kde.org/show_bug.cgi?id=442220). Switching through all rule matching windows by pressing the shortcut multiple times can be more reasonable/usable. So this specific feature is very powerful for advanced workflows. During regular work routines I encountered specific limits of this (IMHO somewhat genius) window rule system.
I don't know exactly how to triage this bug. What it depicts is true, but it is also kind of intended behavior. The window rules are attached by definition to specific windows, not applications. In case of an activation shortcut rule, it lacks information about the application itself, it just knows the actual window. The shortcut is registered when a window matches a rule, and de-registered after that, so it cannot launch the application itself. This explains why the single letter ("K" in the example) appears as text, as there is no shortcut when that happens. If we wanted some shortcut to show this behavior (cycle focus between open instances of an application, or launch a new instance otherwise) I think a more proper place might be the Icons-Only Task Manager. This sounds to me a lot just how icons for pinned apps work, but I'm not sure as I don't use that workflow. About cycling between open windows matching the rule, this is a valid feature request, but would require some "deep" changes on how the shortcut is handled by kwin. It has also been requested in https://bugs.kde.org/show_bug.cgi?id=442220
> The shortcut is registered when a window matches a rule, and de-registered > after that, so it cannot launch the application itself. This explains > why the single letter ("K" in the example) appears as text, as there > is no shortcut when that happens. I see, but though a "already known" hotkey definition, which has temporarly no effect because no Window/Application currently matches the rule, should not write any character which is part of this hotkey. It contradicts the intention of the user. The "cycle focus" behavior would be tightly related to kwin rules, because multiple windows can match a single rule. Like "if focused window matches the rule where shortcut is defined, and this specific shortcut is pressed again, then focus on next matching window". Unfortunately I have no clue how to implement this behavior right now. I think this behavior could be intuitively expected, and is a huge advantage (it could save shortcut combinations for other purposes)
*** Bug 444675 has been marked as a duplicate of this bug. ***
*** Bug 442220 has been marked as a duplicate of this bug. ***
@Ismael I think the icons-only task manager is focused more on mouse usage. Now I use Meta+Alt+D to launch Dolphin instance and Meta+D to focus first instance. Having Meta+D cycle focus multiple instances, or launch a new instance if no instance is launched, could shorten the formula. But this can be solved with Custom Shortcuts and scripts also. Could Custom Shortcuts Settings be the right place to manage more specific shortcut behavior? (KWin Rule Shortcuts should btw also be transparently listed there.) Besides "Global Shortcuts" it is already possible to define "Window Actions" there. But right now it is not possible to Trigger Window Actions with Global Shortcuts. I think that is the missing link which is currently implemented with Window Rules Shortcut. I like the idea of "visual scripting" dbus methods, thats what Custom Shortcuts is already aiming for I guess. ps: sorry for spamming, I just forgot about this bug report *facepalm*