SUMMARY So I have a slightly unusual setup: a main desktop on a homegrown distro that runs LXQt atop fvwm, not KDE, but on which a Konversation started from a VM running Debian testing is almost always running (and often other KDE apps too). I use the M-, and M-. keybindings heavily for switching between tabs in terminator and Konversation and for tags lookup in Emacs. Last weekend Debian testing pulled in Plasma 5.19... and suddenly M-. stopped working as soon as I started any KDE app, while M-, worked fine. Figuring the culprit out took hours and a lot of X restarts and hacking of X to add more capabilities to its grab info reporter and a bug report to Terminator, where I spotted it first. A quick grep showed that /usr/share/kglobalaccel/org.kde.plasma.emojier.desktop was at fault. I don't have the Emoji Chooser installed (or any part of ibus, of which it is apparently part) and I don't want it, but apparently the kglobalaccel code doesn't notice that and grabs the key anyway, then hands it off to a DBus service that doesn't respond because it's not there. Ignoring an apparent Debian mispackaging which prevents me from rebinding or indeed even seeing global keybindings without hand-hacking the config files, and even ignoring the fact that M-. is a key used by a lot of major applications already for all sorts of purposes and stealing it globally is downright unfriendly, and even ignoring the fact that something in KDE should surely have noticed that I had M-. bound as local shortcuts in various KDE apps and that perhaps stealing all of them for a global shortcut was not a good idea... is it really ideal to globally grab and bind shortcut keys when the program that's supposed to be handling them is not even installed? (only the config file is, because it's shipped with plasma-desktop by default) This single helpful keystealing ate ten hours of my time tracking the culprit down. I'd quite like to know that KDE isn't going to steal anything else like this... STEPS TO REPRODUCE (one of many, any application using M-. will be broken systemwide) 1. Install Plasma and uninstall the Emoji chooser. Make sure kglobalaccel is not running yet. 2. Start Emacs. 3. Hit M-. 4. Observe the tag finder pop up in the minibuffer. 5. Start any KDE application. 6. Hit M-. in the already running Emacs. OBSERVED RESULT The second M-. doesn't pop up the tag finder, and nothing else visible happens (kglobalaccel has handed the M-. off to the nonexistent emoji chooser, throwing the keybinding away). EXPECTED RESULT The tag finder pops up. SOFTWARE/OS VERSIONS Linux/KDE Plasma: (homegrown, kernel 5.19.10 + GCC 10.2 + glibc 2.32 + X.org 1.20.9 + FVWM + LXQt + a lot of KDE apps, with many KDE apps running in a separate Debian Testing VM with a TCP/IP connection to the X server) KDE Plasma Version: 5.19 and later: observed with 5.19.5 KDE Frameworks Version: KF 5.74.0 Qt Version: 5.15.1
You say that you have /usr/share/kglobalaccel/org.kde.plasma.emojier.desktop on your system but not emojier? How should the daemon then know that it is not installed? Further you have plasma installed but apparently no shortcuts kcm? That somehow also seems wrong. I would close this as a downstream bug but I think in general the concern is valid. If we have a component in the globalshortcutsrc but no matching desktop file, then don't grab the shortcuts of that. Of course this doesn't work with the non desktop file way of registering shortcuts...
Ugh you're right, that Debian install has got into a mess due to an ancient historical installation and subsequent removal of plasma-desktop: I've managed to end up with plasma-desktop-data (which contains /usr/share/kglobalaccel/org.kde.plasma.emojier.desktop) installed, but not plasma-desktop itself. (In KDE, plasma-desktop depends on plasma-desktop-data, but not the other way around since that would be a circular dependency: so it's quite possible to end up with one installed and not the other.) I raised this against kglobalaccel rather than plasma because I was fairly sure that something like this had probably happened, but that even if it did kglobalaccel shouldn't be grabbing keybindings on behalf of programs that aren't there, no matter how they ended up not being there :)
Perhaps kglobalaccel could do a check to make sure that the app for each global shortcut is actually installed. However this seems like it's getting a bit far in the realm of bending over backwards to handle errors in configuration or packaging. :) Not saying we shouldn't do it, of course.
*** Bug 442056 has been marked as a duplicate of this bug. ***