khotkeys1 had the nice feature of being able to activate a certain window, or run a command if no such window existed, yet. of course, this is now possible as well, but it has been generalized into a true usability nightmare. one possibility would be adding a wizard that guides through creating the two separate entries with opposite conditions and different actions. however, such entry pairs would be hard to maintain once created. so i think the proper solution is adding an action type "shortcut -> unique window (simple)".
See also bug #100794.
"one possibility would be adding a wizard that guides through creating the two separate entries with opposite conditions and different actions" Could someone please explain above?
No idea what Ossi meant, but that sound like a window action that redefines the shortcut when a certain window is added/removed. I'd rather forget such approach to the problem. One would require a shortcut that activates a window, matching certain criteria and if such window does not exist, runs an executable instead. That's however still not simple because of the "certain criteria" - there's at best a loose connection between a process binary name and the WM_CLASS window property, but that doesn't tell you whether to activate WM_CLASS with WM_NAME "Document #1" or "Document #2" or whether a dialog type matching WM_CLASS is ok or you want a normal window or whether the role should be "browser" or "downloads" etc. etc. => The programs service file would have to hint such - or one has to live with glitches - or it's not *that* simple to create such shortcut.
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.
Nate, I think that mass-closing all issues with kcm_khotkeys set as a component is wrong. I suspect many of them are genuine problems with how KDE handles keyboard shortcuts and the fact that the component which handles shortcuts changed in no way automatically invalidates these problems. I think in all such open issues the component should be updated to the current one (KGlobalAccel) and there should be a note added with information to check if a problem is still present now, when the component is different.