Re: KGlobalAccel on non-Plasma systems
Hi, I agree that it's most useful on plasma. >On systems that do not use X11 (Windows, macOS, Android) it >is most likely not useful at all. There exists code for mac and windows but I don't know either if it's working or just a dummy so it compiles. Also for everyone interested in the topic, KGlobalAccel will be a topic on Saturday's frameworks meeting 15.00 CEST at meet.kde.org. Seems like it ties into the topic of different frameworks types as observed by Nicolas. Regards, David
Re: KGlobalAccel on non-Plasma systems
On Tue, Apr 6, 2021 at 5:30 PM 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 > Hi Nico, It makes a lot of sense. And TBH, my first thought was "h n". But then it kind of does make sense. KGlobalAccel has a lot of logic to centralise these shortcuts settings and in practice it's nothing that would be realistically mappable to a non-Plasma system. So in general, yes. +1 Aleix
Re: KGlobalAccel on non-Plasma systems
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
Re: KGlobalAccel on non-Plasma systems
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 >
KGlobalAccel on non-Plasma systems
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
