Reworking how shortcuts are registered and saved
I have a couple of patches open or in work that are sort of related. To make discussing them easier I thought I'd write down the high-level ideas and vision behind them.
Status quo: We have two ways for applications to define shortcuts:
- Registering them at runtime using the KGlobalAccel C++ API. This internally talks to the shortcut daemon (kglobalaccel5 on X11 and kwin_wayland on Wayland) via DBus
- Installing .desktop files to
/usr/share/kglobalaccel
. Each desktop file action as well as the whole desktop file can have aX-KDE-Shortcuts
property set to specify a shortcut. Usually the files in/usr/share/kglobalaccel
are symlinks to files in/usr/share/applications
When a shortcut is registered at runtime it is saved to .config/kglobalshortcutsrc
with its id, user-visible name, current shortcut, and default shortcut
New desktop files in /usr/share/kglobalaccel
are read once and then are stored in .config/kglobalshortcutsrc
the same way as runtime-registered shortcuts are saved.
The status quo has several problems:
- The C++ API of KGlobalAccel is not very intuitive. It is somewhat tied to KActionCollection, which is problematic in a QML context
- With runtime-registred shortcuts actions only appear in the KCM once the relevant program has run at least once
- With runtime-registred shortcuts actions don't get removed from the KCM after the relevant program has been uninstalled or the action was removed by an update https://bugs.kde.org/show_bug.cgi?id=429589
- With desktop file shortcuts the user-visible names are never updated after they are read once, so any change (e.g. adding translations) will not be reflected
-
kglobalshortcutsrc
contains redundant information such as the user-visible names that aren't actually configuration -
kglobalshortcutsrc
explicitly contains all config information, not just non-default config information. That way it behaves differently to most config files and e.g. prevents distributions/administrators from providing their defaults via the usual way https://bugs.kde.org/show_bug.cgi?id=456958 - When files in
/usr/share/kglobalaccel
are symlinked to/usr/share/applications
then local modifications in.local/share/applications
are not respected https://bugs.kde.org/show_bug.cgi?id=430498
Proposed direction:
As already discussed in https://phabricator.kde.org/T12063 I think we should move more towards defining shortcuts as desktop files. Having the information available statically and in a declarative way helps with a lot of the problems. plasma/kscreen!126 (merged) is an example how that would look like
However, there are more steps needed.
We should remove the redundant information from kglobalshortcutsrc
and only store actual, non-default configuration information. !56 (closed) demonstrates how that could look like for desktop file based shorcuts. With runtime-registered shortcuts it's more difficult since there having some kind of cache of known things is important since not everything is running all the time.
Currently for applications to register their desktop-file defined shortcuts they need to install a copy/symlink of their .desktop file to /usr/share/kglobalaccel
. See utilities/konsole!723 (merged) for a case where this was missed. To simplify things and remove redundant sources of information we should consider desktop files in /usr/share/applications
directly.
Implementation-wise we should move all of the desktop file processing we do currently to KService, which would solve a number of problems we have (it provides us caching via ksycoca, notifies when new entries are available/changed, handles cascading properly etc). !68 (closed)
We also want to use ApplicationLauncherJob for executing actions, so we need to find a way we can depend on it.