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 >
