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.

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 T12063#208760, @davidedmundson wrote:

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.

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

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.

As a prototype I made kglobalaccel use dbus activation (https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#dbus) if the desktop file specifies it is dbus activatable instead of manually parsing Exec fields. Also a patch for spectacle to see how it would work.
https://invent.kde.org/frameworks/kglobalaccel/commit/78baef0af7ec56db115f9e2c726a714a8684761b
https://invent.kde.org/graphics/spectacle/commit/a43c16d395ef5c0f0373ccfa555db783052b6797

Imo much better than using qdbus or dbus-send in exec fields.

In T12063#211622, @graesslin wrote:

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.

I fully agree with this. In fact I made a change to kglobalaccel to prevent it from running on non-Plasma systems: https://invent.kde.org/frameworks/kglobalaccel/-/commit/48c3376927e5e9c13377bf3cfc8b0c411783e7f3

However we ended up reverting it since it broke KWin's shortcuts when running on LXQt

It is not cross-platform and not even cross-desktop

That's not entirely true. kglobalaccel actually has implementations for Windows and macOS: https://invent.kde.org/frameworks/kglobalaccel/-/tree/master/src/runtime/plugins

However it appears odd to me from an architectural PoV: As far as I can tell kglobalacceld registers the shortcuts and then uses DBus(?) to communicate back to the application. That's difficult at best on Windows/macOS since you need to ensure a dbus-daemon is running.

This is yet another case where we are mixing implementation (kglobalacceld/kwin) with interface.

On Windows/macOS the app itself should probably register the shortcut with the OS instead of going through kglobalacceld.

Something else to consider is that there is a global shortcut portal in development: https://github.com/flatpak/xdg-desktop-portal/pull/711

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

According to https://invent.kde.org/frameworks/kglobalaccel/-/blob/master/src/kglobalaccel.h#L95 Plasma uses this

I can't find any actual use of that function though

https://invent.kde.org/frameworks/kglobalaccel/-/issues/3 outlines some plans I have for kglobalaccel