KGlobalAccel cleanup and improvement for desktop files
Open, Needs TriagePublic

Description

If we want to drop KHotkeys T2050 we should make working with KGlobalAccel as comfortable as possible.
Currently there is a

  • Mix of functions that require a QStringList or a QAction parameter
  • Some methods are static and others require the singleton object
  • There are still some methods around that are deprectated since KDE 4 times

Additionally the API is cumbersome to use because you need the action setShortcut was called on or one that looks like it. If the shortcuts are defined in a desktop file that means
manually constructing QActions and duplicating the strings in the desktop file. Interacting with KGlobalAccel though these QAction parameters is not transparent. It just works if you use KActionCollection (if your program name matches your componentName which I don't know if this is the case when using desktop files). But when you have to manually construct actions because you want to query information about the shortcuts defined in you desktop file there is no documentation that the objectName and componentName and componentDisplayName properties need to be set to their specific values
In the future if we want to embrace the use of desktop files also for shortcuts there should be an easy to use API for that. I have no idea how such an API could look like (actionsFromDesktopFile() or automagically shortcutsForThisApplication()?) so ideas are welcome.

Does anyone know of any user of Shortcut Contexts? Or is that feature just not needed?

There is also a fast path in some functions that assumes that every shortcut had a setShortcut call before and doesn't query the runtime again. This obviously falls flat if the shortcuts are defined outside of the program. This can of course be worked around locally to use the global functions (for example in KShortcutsEditor in KXmlGui) but maybe something to think about in a post programs call setShortcut at startup world.

Other ideas:
@fvogt: Decouple it from QKeySequence

Related Objects

davidre created this task.Mon, Nov 18, 10:09 AM
davidre added a parent task: T2050: sunsetting KHotKeys.
davidre renamed this task from KGlobalAccel cleanup and improvement for desktop filess to KGlobalAccel cleanup and improvement for desktop files.
broulik added a subscriber: broulik.EditedMon, Nov 18, 10:11 AM

Yeah, I find the API quite cumbersome, there's setShortcut, setGlobalShortcut, setDefaultShortcut, etc. Everyone I've seen use KGlobalAccel does a different combination of random calls until it works.

For Plasma mobile the ability to do "long press" global shortcuts is needed, so one can do the following:

  • tap power button to wake/lock
  • press and hold power button to invoke Leave menu

The configuration itself is also a bit of a mess, leaving it entirely up to the application to set a sensible "display name" and/or using KActionCollection.
Changing the configuration through scripts/migrating shortcuts is also super hard and error-prone.

davidre added a comment.EditedMon, Nov 18, 10:13 AM

Another thing is the magic isConfigurationAction property that is used which changes behavior of some functions if present which doesn't make things easier if you want to configure stuff and you have to read the code to see if you need it or not.

In the future if we want to embrace the use of desktop files also for shortcuts.

IMHO having a desktop file specifying DBus callbacks is working well enough that it should be the sole way of an app registering global shortcuts. Then we only need code in client apps if they want to do any kind of configuration

The old method suffers from not working before an app is first run, and not cleaning up when an app is removed.

It'd be a radical change, but global shortcuts are generally used by plasma not apps.

We have this new infra in-place already, so we could try and build on that, port things and see how it goes already.

In the future if we want to embrace the use of desktop files also for shortcuts.

IMHO having a desktop file specifying DBus callbacks is working well enough that it should be the sole way of an app registering global shortcuts. Then we only need code in client apps if they want to do any kind of configuration

The old method suffers from not working before an app is first run, and not cleaning up when an app is removed.

It'd be a radical change, but global shortcuts are generally used by plasma not apps.

We have this new infra in-place already, so we could try and build on that, port things and see how it goes already.

Fully agree that dbus-callbacks is the way to go. As written above I think if we go that route the current client API is just not suited for this because you need to do all this setting up of QActions if you just info about the current shortcuts (not even configuration!) and have to be careful to call the right method query the runtime and bypass the local cache.

ognarb added a subscriber: ognarb.Mon, Nov 18, 2:14 PM

Not sure it's relevant to KGlobalAccel but related to long press, do we want to add gesture to KGlobalAccel? Touch gestures for the touchpad or touchscreen can be very powerful shortcuts too

davidre moved this task from Backlog to Needs Input on the KF6 board.Fri, Nov 22, 8:51 AM

Radical suggestion: remove kglobalaccel from frameworks and put it into Plasma. Kglobalaccel fails as a framework. It is not cross-platform and not even cross-desktop. X11 backend cannot ensure that the shortcut is not taken by another process, the Wayland backend is KWin specific. We hardly have any applications outside of Plasma using KGlobalAccel. Looking at lxr I can see a few media applications, but we already bind the shortcuts to mpris. There seem to be some API abuses like Chokoq having a global shortcut to update the timeline or konversation to switch to the next active tab.

My suggestion would be to go through all usages in application and decide whether we still need them or whether we can better define them through a desktop-file shortcut. If we can get that maybe we could find a standardized way by extending the desktop file spec.

If we move it to Plasma we can cleanup kglobalaccel much better and also better break the API and better support future things such as mouse shortcuts or the things @ognarb mentions. The touchpad and touchscreen support in KWin/Wayland was implemented with a future support for globalaccel in mind, but not on the current codebase, not as a cross-platform API.

Radical suggestion: remove kglobalaccel from frameworks and put it into Plasma.

After looking more in depth at the sprint we still need public API for clients to detect that their internal shortcuts don't interrupt global shortcuts even if they don't use global shortcuts themselves.

That means we need the reading available for KXMLGui even if in practice that feature only works on Plasma.