Splitting KGlobalAccel interface and runtime

[Vlad Zahorodnii]

On 2/13/23 22:05, Nicolas Fella wrote:
> 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?

+1

There's one caveat though: given that the library and the runtime parts 
will have different release schedules, we will have to be careful about 
protocol changes. Perhaps we could borrow a thing or two from activities?

Regards,
Vlad