Bug 89178

Summary:	want simple possibility to specify "singleton" app-bindings
Product:	[Applications] systemsettings	Reporter:	Oswald Buddenhagen <ossi>
Component:	kcm_khotkeys	Assignee:	Lubos Lunak <l.lunak>
Status:	REOPENED ---
Severity:	wishlist	CC:	bugs.kde.org
Priority:	NOR
Version:	5.20.3
Target Milestone:	---
Platform:	Compiled Sources
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Oswald Buddenhagen 2004-09-09 17:38:09 UTC

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)".

Comment 1 Lubos Lunak 2005-03-07 10:15:15 UTC

See also bug #100794.

Comment 2 Piotr Dobrogost 2015-10-21 07:31:41 UTC

"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?

Comment 3 Thomas Lübking 2015-10-21 21:06:15 UTC

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.

Comment 4 Nate Graham 2024-03-04 19:41:50 UTC

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.

Comment 5 Piotr Dobrogost 2024-03-06 09:23:40 UTC

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.