| Summary: | Unify shortcut configuration by merging existing shortcuts to KHotKey | ||
|---|---|---|---|
| Product: | [Applications] systemsettings | Reporter: | Dennis Schridde <heri+kde> |
| Component: | kcm_khotkeys | Assignee: | Lubos Lunak <l.lunak> |
| Status: | RESOLVED UNMAINTAINED | ||
| Severity: | wishlist | CC: | ctibor.brancik, javi.azuaga |
| Priority: | NOR | ||
| Version First Reported In: | 5.20.3 | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
This bug has been inherited from KControl to SystemSettings: Why is Actions still alone instead of been inside of Mouse/Keyboard options? I find this confusing. Some proposal is here: http://wiki.kde.org/tiki-index.php?page=System Settings I think this bug has been made obsolete by redesign of the systemsettings by the 4.5 version line. (In reply to comment #3) > I think this bug has been made obsolete by redesign of the systemsettings by > the 4.5 version line. No, the idea was that there are less places (and possibly APIs, but I don't know about the implementation) to configure shortcuts. There are still 3 of them: Custom Shortcuts (with predefined actions), Standard Shortcuts, Global Shortcuts. My proposal was to merge those into one simpler dialogue with something like an "advanced" option. Sorry for the "delay" ;-)
It would be possible to have all shortcut related items in the same kcm group of systemsettings (ie. you get one settings page with three tabs) but it's not possible to merge them - at least it's ipossible to merge the khotkeys kcm with that one of the general global shortcuts.
The reason is that for the global shortcut system (kcmshell5 keys) the applications define a bunch of actions and register them with kglobalaccel, but for khotkeys the user defines a list of actions (and registers them with kglobalaccel), ie. "kcmshell5 khotkeys" does what usually has been done by the application developer.
The only thing beyond could be that khotkeys visibly registers its actions with kglobalaccel, so that in "kcmshell5 keys" a component "User actions" or similar shows up, listing the khotkeys actions (but only the shortcut could be edited there) as well as a special "Standard actions" entry which lists the standard actions.
What's preventing the latter is that those are three different components, ie. khotkeys mandates kglobalaccel, but the standard actions do not.
This:
> If a configured trigger is triggered, KHotKeys informs the App that the appropriate action should be done.
is *completely* not in the cards (if it pointed "standard actions").
If kglobalaccel sucks a shortcut, it's away from *all* clients. It could then only work for applications which participate in such extended, ie. you could not use XF86Back in firefox etc.
The local shortcuts *cannot* be processed through kglobalaccel.
tl;dr
One could add a "User actions" item to "kcmshell5 keys", but that's it.
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. |
Version: (using KDE KDE 3.4.0) Installed from: Gentoo Packages Compiler: gcc (GCC) 3.4.3-20050110 (Gentoo Linux 3.4.3.20050110-r2, ssp-3.4.3.20050110-0, pie-8.7.7) OS: Linux I think having 2 dialogues in KControl to configure shortcuts("normal" and khotkeys) is not the best idea. I would prefer if this could be merged together by making "normal" shortcuts use khotkeys and perhaps give khotkeys another (additional) view(so one can use the "normal" dialogue with all those predefined actions and have another view like khotkeys is today). I have to admit that I have no idea about the current implementation, but I think it could work like this: AppX defines certain actions it provides (in a separate file or inside the sources?) KHotKeys reads this (on KDE-Startup) and creates a hirarchical list. It scans it's own config and glues the triggers(e.g. keypressevents) and those actions together. If a configured trigger is triggered, KHotKeys informs the App that the appropriate action should be done. The App grabs this event and executes the code that it associates with the action. (This would work like sending a DCOP-signal, perhaps _by_ sending a DCOP-sig(or would this overload DCOP?)) The configuration (event->action) would be like KDCOP shows DCOP-functions(To make it usable): In settingsmenu for a Results->Action (see bug #89195) : "Action-that-will-be-done-selector": |-> App1 | |-> Group1 | | |-> Action1 | | |-> Action2 | |-> Group2 | |-> Action1 | |-> Action2 |-> App2 (I think of a configuration-style like my last edit in Bug #89195) The other view would be like this: Configurationwidget: |-> App1 | |-> Group1 | | |-> Action1 --> Define triggerevent | | |-> Action2 --> Define triggerevent | |-> Group2 | |-> Action1 --> Define triggerevent | |-> Action2 --> Define triggerevent |-> App2 So the user has the ability to create shortcuts like he can currently, which is better for some purposes.