Splitting KGlobalAccel interface and runtime

[Nicolas Fella]

Hi,

the kglobalaccel framework currently contains two pieces: kglobalacceld,
the runtime component that manages global shortcuts, and an
application-side library to interact with it.

The two communicate with each other via DBus. On X11 there is a
standalone kglobalacceld5 process providing the interface, on Wayland
the runtime is linked into KWin and thus the kwin_wayland process
provides the interface.

The current architecture has a number of downsides:

- Any call to the KGlobalAccel library may DBus-activate the
kglobalacceld5 process, which may be undesired on Desktop other than
Plasma since it competes with their native shortcut system. We tried
fixing that by making such calls no-op on !Plasma, but that broke things
for people that did want it to run, for example people using KWin with
LXQt, because KWin relies on KGlobalAccel for shortcuts

- We want to keep the dependencies of the interface library minimal,
which is inconvenient for the development of the runtime part. For
example we really want to use KIO::ApplicationLauncherJob in the
runtime, but currently can't, because that would introduce a dependency
cycle in Frameworks (KIO depends on KXmlGui, which depends on
KGlobalAccel, which would depend on KIO)

- Coinstallability of KF5 and KF6. Conceptually there can only be one
kglobalacceld. If both KF5 KGlobalAccel and KF6 KGlobalAccel install a
kglobalacceld this is going to be problematic. This also means that a
KF6-based kglobalacceld must work with a KF5 interface library

- Other shortcut daemon implementations. Since somewhat recently there
is an XDG Portal for global shortcuts. Platforms like Windows and macOS
also have ways for applications to register global shortcuts. While we
are currently not using any of these it's very well possible that we
would eventually want to use the KGlobalAccel interface library to
interact with those. Having the kglobalacceld runtime in the same
frameworks therefore doesn't feel right.

To address these issues I suggest we split out the runtime part of
kglobalaccel into its own project, under the Plasma release group,
because that's primarily where it's used/supported. The interface
library would remain in frameworks. We have a similar situation with
activities, where the manager (kactivitymanagerd) is in Plasma and the
interface is in Frameworks. When doing this we'd also change the way how
kglobalacceld is started away from DBus activation towards explicitly
starting it as part of the Plasma startup. This avoids accidentally
launching it when it shouldn't be but still allows to explicitly start
outside of Plasma if really wanted. It would also allow for greater
flexibility in the development of the runtime, especially around
dependency constraints.

It wouldn't automatically solve the coinstallability problem of KF5 and
KF6, because a kglobalacceld provided by KF5-KGlobalAccel would still
conflict with a Plasma-provided kglobalacceld, but it's at least
conceptually less messy since it's clear that the Plasma-provided one
would be the preferred one to use.

Thoughts about this?

Cheers

Nico