Bug 435420

kglobalaccel5 is the KDE equivalent of lxqt-globalkeysd. It should only be autostarted when you're in a Plasma session. Are you saying that it gets autostarted when you're in an LXQt session too? Do any other KDE processes get autostarted, or just kglobalaccel?

Technically it isn't autostarted at all, it's DBus-activated.

What probably happens is that some KDE software you are running calls some API of the KGlobalAccel which then makes a DBus call to the kglobalaccel daemon, resulting in it getting started.

Preventing that from happening is easy enough, but before I make a patch doing so I want to check that I'm not missing a legitimate use case.

Let's wait for some feedback on https://mail.kde.org/pipermail/kde-devel/2021-April/000406.html

(In reply to Nate Graham from comment #1)
> Are you saying that it gets autostarted when you're in an LXQt session too?

Yes, it gets autostarted in LXQt too.

> Do any other KDE processes get autostarted, or just kglobalaccel?

I logged in a brand new login id called "ethan" and ran "pgrep -aU ethan > ethan-procs.txt". This user has no customized configuration.

I have pasted the contents below. The summary is that kdeconnect and kwallet autostart too, but I don't mind them. KWallet does not get in my way, so I don't care about it autostarting, and kdeconnect is something I use in LXQt, so I'm happy with it autostarting. To the LXQt session, kglobalaccel5 and krunner are the harmful processes. kactivitymanagerd and baloorunner are minor annoyances in LXQt too, but they don't get in the way of the LXQt session, they only consume some RAM. Incidentally, krunner, kactivitymanagerd and baloorunner don't autostart in my regular login (not ethan), so they can probably be controlled via the LXQt or Plasma configuration.

% cat ethan-procs.txt
1057 /usr/lib/systemd/systemd --user
1058 (sd-pam)
1068 /usr/bin/kwalletd5 --pam-login 7 8
1069 lxqt-session
1074 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
1102 /usr/bin/openbox --config-file /home/ethan/.config/openbox/lxqt-rc.xml
1107 /usr/bin/kaccess
1108 /usr/bin/pcmanfm-qt --desktop --profile=lxqt
1109 /usr/bin/lxqt-globalkeysd
1110 /usr/bin/lxqt-notificationd
1111 /usr/bin/lxqt-panel
1112 /usr/bin/lxqt-policykit-agent
1113 /usr/bin/lxqt-runner
1116 /usr/bin/xscreensaver -no-splash
1118 /usr/bin/nm-applet
1121 /usr/lib/kdeconnectd
1122 xscreensaver-systemd
1124 /usr/bin/kgpg
1137 /usr/bin/kglobalaccel5
1145 /usr/lib/dconf-service
1152 /usr/lib/at-spi-bus-launcher
1158 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3
1173 /usr/lib/at-spi2-registryd --use-gnome-session
1277 /usr/bin/pipewire-pulse
1282 /usr/bin/pipewire
1283 /usr/bin/pipewire-media-session
1315 /usr/bin/lxqt-powermanagement
1350 /usr/bin/gpg-agent --supervised
1362 /usr/bin/krunner
1374 /usr/lib/kactivitymanagerd
1393 /usr/lib/baloorunner
1397 kdeinit5: Running...       
1398 /usr/lib/kf5/klauncher --fd=8
1403 /usr/bin/qps
1419 /usr/bin/kitty
1427 /bin/bash

(In reply to Nicolas Fella from comment #2)
> Preventing that from happening is easy enough, but before I make a patch
> doing so I want to check that I'm not missing a legitimate use case.

The first thing I do on each login on LXQt is execute: pkill ".*global.*" && lxqt-globalkeysd --daemon

I plan to automate this part, but haven't gotten around to it yet. So if it helps answer the question of the use case, I need to kill the process to make my LXQt session function in a normal manner.

What probably happens is that kaccess is autostarted (since it is in /etc/xdg/autostart) and that triggers kglobalaccel.

I guess kaccess should be changed to only autostart in Plasma then

Git commit f701c66dc37343bfb01062aa09dc4a2040ea7d4c by Nicolas Fella.
Committed on 08/04/2021 at 12:52.
Pushed by nicolasfella into branch 'master'.

Only start kaccess in Plasma

kaccess is an implementation detail of Plasma. It should not be launched
when the user is running another DE while Plasma is installed.

M  +1    -0    kaccess/kaccess.desktop

https://invent.kde.org/plasma/plasma-desktop/commit/f701c66dc37343bfb01062aa09dc4a2040ea7d4c

(In reply to Nicolas Fella from comment #6)

Thank you! I made this change in my own /etc/xdg/autostart/kaccess.desktop, and it fixed the problem.

Should I mark the bug as resolved or will that be done by the dev team?

(In reply to prash from comment #7)

Sorry, I wrote to soon. The change to kaccess.desktop only partially fixes the problem. kglobalaccel5 no longer autostarts on login, but it starts the moment I start dolphin. Presumably, many other KDE apps might trigger it to start too.

(In reply to prash from comment #8)

After a bit of triangulating, it appears that merely opening a KDE app will not autostart kglobalaccel5. On a fresh session, when I opened Okular, there were no processes that were out of the ordinary. However, the moment I did a File->Open or File->Open Recent from there, I got something like this:

12590 /usr/lib/kactivitymanagerd
12599 /usr/bin/kglobalaccel5

Of course, dolphin starts these processes too.

Again, on fresh sessions, KCalc, KCharSelect, KDiff3, Kompare did not trigger kactivitymanagerd or kglobalaccel5, even after performing a File->Open or an equivalent. I have no idea why both dolphin and okular would repeatably trigger these.

A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kglobalaccel/-/merge_requests/19

Git commit 48c3376927e5e9c13377bf3cfc8b0c411783e7f3 by Nicolas Fella.
Committed on 19/04/2021 at 22:26.
Pushed by nicolasfella into branch 'master'.

Prevent kglobalaccel5 getting activated on non-Plasma systems

While in theory kglobalaccel works on any X11 system we don't want it to run on non-Plasma systems. It isn't very useful and may interfere with the desktop's native shortcut system.

Calling some API of KGlobalAccel may result in a DBus call to the daemon which then may launch by DBus activation. Prevent that from happening on non-Plasma systems.
Related: bug 430691

M  +80   -0    src/kglobalaccel.cpp

https://invent.kde.org/frameworks/kglobalaccel/commit/48c3376927e5e9c13377bf3cfc8b0c411783e7f3

I am not sure this is a step in the right direction. I am using KWin + LXQt and KWin relies on kglobalaccel5. Thus KWin without KDE is basically broken with this patch, unless the user finds out about this behavior.

Then there is a larger discussion if disabling all application's global shortcuts unless you are running on KDE is what the user wants. To me it seems the breakage is bigger if we deactivate kglobalaccel5. 

Unfortunately I do not have a clear idea what to do. Could the original report give us some info on which are the clashing hotkeys? Maybe there would be some way to distinguish plasma-specific hotkeys?

So you don't want kglobalaccel to run when Plasma is also installed but not active, and you do want it to run when using KWin as the window manager in LXQt?

(In reply to Nate Graham from comment #13)
> So you don't want kglobalaccel to run when Plasma is also installed but not
> active,

Well that is what @prash wanted, not me. I understand where he is coming from (colliding keyboard shortcuts), but it silently breaks my use-case. And I believe that it is not an ideal solution in general.

Case in point, Amarok has some useful global shortcuts using KGlobalAccel [1], e.g. for skipping tracks, that you would like to work even if the current environment is not plasma. Currently, these shortcuts will stop working.

> and you do want it to run when using KWin as the window manager in
> LXQt?

KWin is pretty unusable without kglobalaccel (even alt-tab does not work). Or at least it seems to me that KWin needs it running (from quick look at the sources), maybe there is other way?

I personaly have no problem setting the XDG_CURRENT_DESKTOP=KDE environment variable or patching kglobalaccel, I just wanted to inform you abot these issues. And maybe provide users with broken KWin shortcuts something to search for :).

[1]https://github.com/KDE/amarok/blob/e09665e6b1298de7a8e442a7d530d4ec23ab283f/src/MainWindow.cpp#L957

> Amarok has some useful global shortcuts using KGlobalAccel [1], e.g. for skipping tracks, that you would like to work even if the current environment is not plasma. Currently, these shortcuts will stop working.

That is true, but for media players the basic shortcuts (play, pause, skip, back) should *not* be handled by the app itself but by the MPRIS integration. Also, there is a tradeoff to be made, and we considered not breaking a systems shortcut system more important than having shortcuts in Amarok.

IMO the proper solution would be to make lxqt-globalkeysd trigger the relevant stuff in KWin. It probably requires some work on KWin to expose the necessary bits as DBus API, but in the end it's the best solution

I'm not sure if if you still need me to list out the clashing hotkeys. There are quite a lot of them (if I add openbox+lxqt vs KDE).

A more general solution I would prefer is if you could make all these services configurable from their respective .desktop files with:

    OnlyShowIn=KDE

Could you also please look controlling the autostart of kactivitymanagerd in a similar manner? That way, the user who wants the service can copy the relevant file from /etc/xdg/autostart to ~/.config/autostart and modify the line to

    OnlyShowIn=KDE;LXQt

After all, this is the standard way of controlling services in LXQt, and maybe other DEs.

Git commit 9a48818abf50340e31d718cc675501dec6c51429 by Nate Graham.
Committed on 26/05/2021 at 19:14.
Pushed by ngraham into branch 'master'.

Revert "Prevent kglobalaccel5 getting activated on non-Plasma systems"

This reverts commit 48c3376927e5e9c13377bf3cfc8b0c411783e7f3.

This change broke users of KGlobalAccel run outside of the Plasma
Desktop. This sort of behavior change probably needs to be made during
a major transition like KF6 so that developers have some notice and it
doesn't randomly change and break stuff unexpectedly.
Related: bug 437034
FIXED-IN: 5.83

M  +0    -80   src/kglobalaccel.cpp

https://invent.kde.org/frameworks/kglobalaccel/commit/9a48818abf50340e31d718cc675501dec6c51429

The change was reverted as it broke legitimate users of KGlobalAccel outside of Plasma. Re-opening this.

(In reply to Nate Graham from comment #18)
> The change was reverted as it broke legitimate users of KGlobalAccel outside
> of Plasma. Re-opening this.

Could you please make the autostart of kactivitymanagerd and kglobalaccel5 manageable via their .desktop files? This will solve the issue for both kinds of use-cases. People can configure its autostart from within ~/.config/autostart.

As I have mentioned before kglobalaccel is not autostarted via the usual autostart mechanism. The process is launched via DBus activation the first time something makes an API call to it