KGlobalAccel on non-Plasma systems

[Konstantin Kharlamov]

Just to clarify a bit: by "only running on Plasma system" do you mean running
when $XDG_CURRENT_DESKTOP = KDE? Or something else?

The reason I'm asking is because I'm a user of Plasma + i3wm, and having various
shortcuts automatically set up by Plasma (specifically: screen brightness,
various multimedia keys) is certainly one of the reasons I love this
combination. I wouldn't want to see it break. This combination has
$XDG_CURRENT_DESKTOP set to KDE, so it is safe in that regard.

On Tue, 2021-04-06 at 17:29 +0200, Nicolas Fella wrote:
> Hi,
> 
> we received a few reports [1] [2] from people using non-Plasma systems
> that the kglobalaccel5 process was started, leading to clashes with the
> native global shortcut system.
> 
> This seems to happen when apps call some API of KGlobalAccel which
> results in the kglobalaccel5 process to be DBus-activated.
> 
> This brings me to the question of whether there is a use case for using
> KGlobalAccel on non-Plasma systems at all. While technically
> KGlobalAccel should work on all X11 systems most (all?) desktop
> environments have their own way of global shortcut handling that we
> should not interfere with. On Wayland it is only working in combination
> with KWin. On systems that do not use X11 (Windows, macOS, Android) it
> is most likely not useful at all. api.kde.org lists only Linux and
> FreeBSD as supported, but the code contains special casing for non-Unix
> platforms and for macOS.
> 
> At the recent Frameworks sprint we talked about better communicating
> whether a given Framework is truly a cross-platform/cross-desktop
> library or an implementation detail of Plasma/used for integrating with
> Plasma [3]. It seems to me that KGlobalAccel falls into the latter
> category.
> 
> If we agree that KGlobalAccel is only relevant when running Plasma we
> should take the necessary steps to ensure it does not get activated in a
> non-Plasma environment to avoid nasty side effects. Clearly defining the
> scope would also help frameworks and app developers make technical
> decisions and would allow to clean up some unneeded code.
> 
> Thoughts?
> 
> Cheers
> 
> Nico
> 
> [1] https://bugs.kde.org/show_bug.cgi?id=435420
> 
> [2] https://bugs.kde.org/show_bug.cgi?id=430691
> 
> [3] https://phabricator.kde.org/T14294
>