That will continue to work. The window manager doesn't really matter
here, at least on X11.
On 06.04.21 20:31, Konstantin Kharlamov wrote:
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
