SUMMARY If plasmashell is restarted, kglobalaccel5 becomes unable to activate Task Manager windows through keyboard shortcuts. This does not break kglobalaccel5 entirely since Menu and KRunner still run. Kglobalaccel5 must be killed and rerun in order for Task Manager keybindings to work again. I believe this means kglobalaccel does not fully recover after plasmashell either being killed or manually run. STEPS TO REPRODUCE 1. plasmashell --replace 2. Use Global Shortcuts for Task Manager entries (Meta+1, 2, 3...). WORKAROUND 1. Open Krunner 2. killall kglobalaccel5 && kglobalaccel5 SOFTWARE/OS VERSIONS Operating System: Kubuntu 19.04 KDE Plasma Version: 5.15.4 KDE Frameworks Version: 5.56.0 Qt Version: 5.12.2 Kernel Version: 5.0.0-15-generic ADDITIONAL INFORMATION I'm not sure if this bug should be reported on frameworks-kglobalaccel or plasmashell.
Interesting, can confirm.
Are you using Latte dock or something?
No, the default plasma panel. I haven't test it with Latte Dock. Additionally, I just tested it again and this occurs with icons-only task manager as well as the default task manager.
Hello, I noticed another thing: plasmashell --replace == breaks task manager shortcuts killall plasmashell ; plasmashell == doesn't break task manager shortcuts Can you reproduce this?
(In reply to Thiago Sueto from comment #4) > Hello, I noticed another thing: > plasmashell --replace == breaks task manager shortcuts > killall plasmashell ; plasmashell == doesn't break task manager shortcuts > > Can you reproduce this? I can confirm on Arch Linux. Operating System: Arch Linux KDE Plasma Version: 5.19.4 KDE Frameworks Version: 5.72.0 Qt Version: 5.15.0
Apparently: killall plasmashell ; plasmashell --replace == not breaks killall plasmashell ; plasmashell == not breaks killall plasmashell ; kstart5 plasmashell == not breaks kquitapp5 plasmashell ; plasmashell --replace == breaks kquitapp5 plasmashell ; plasmashell == breaks kquitapp5 plasmashell ; kstart5 plasmashell == breaks Does plasmashell --replace use kquitapp5 to exit a running instance of plasmashell? If so, it seems likely to me the issue is in kquitapp5 and this would also explain why plasmashell --replace doesn't have this issue when no plasmashell instance is currently running.
*** Bug 425326 has been marked as a duplicate of this bug. ***
Curiously enough, restarting Plasmashell via the new systemd startup works fine too.
I assume kglobalaccel doesn't notice that plasmashell went away and thinks the shortcuts are already taken.
I assume kglobalaccel doesn't notice that plasmashell went away and thinks the shortcuts are already taken. --replace does the equivalent of calling kquitapp, i.e. calls org.qtproject.Qt.QCoreApplication.quit so we are probably missing some cleanup in this case.
The same issue occurs every time I open System Settings (which launches the Quick Settings page). Opening the Info Center does not cause this issue. Operating System: Arch Linux KDE Plasma Version: 5.21.90 KDE Frameworks Version: 5.82.0 Qt Version: 5.15.2 Kernel Version: 5.12.8-arch1-1 (64-bit) Graphics Platform: X11 Processors: 12 × AMD Ryzen 5 5600X 6-Core Processor Memory: 15.6 GiB of RAM Graphics Processor: NVIDIA GeForce GT 730/PCIe/SSE2 I don't know if this occurs on Plasma 5.21, since I'm on 5.22 beta.
Possible root cause of Bug 431925? It seems fairly intermittent, which could be explainable by the behavior described here.
*** Bug 431925 has been marked as a duplicate of this bug. ***
Opening systemsettings is surely unrelated to this bug. Suspecting is actually a plasma issue, if it's missing cleanup?
This was an amazingly useful bug report. With knowing it's cased by --replace, the bug is super obvious. I'd wasted ages on the previous report and got nowhere. ShellCorona ctor runs before the service is registered. For --replace that means it's run before the old one quits. kglobalaccel understandably gets confused. Fortunately this means no regular user will ever hit this and as such isn't a huge priority. For crashes the order is as-expected In any case I'll move these methods into some sort of ShellCorona::init() and call that after the KDbusService line.
Well, it's annoying for people like us. :)
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/931
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/933
Git commit 9b9b6e5d9bb7308ea47b99eac4044517a8a80ee4 by David Edmundson. Committed on 15/06/2021 at 21:20. Pushed by davidedmundson into branch 'master'. Init ShellCorona after KDBusService ShellCorona is created before KDBusService which registers the name. This causes a problem as we register global shortcuts before plasmashell --replace has kiled the old application, which in turn deregisters everything. We want everything before KDBusService to be as light as possible. Moving ShellCorona construction is not trivial as some argument parsing uses that. M +4 -1 shell/main.cpp M +3 -0 shell/shellcorona.cpp M +1 -0 shell/shellcorona.h https://invent.kde.org/plasma/plasma-workspace/commit/9b9b6e5d9bb7308ea47b99eac4044517a8a80ee4
Git commit 2a67a010677323a0ec2569510207dbd34031b816 by David Edmundson. Committed on 15/06/2021 at 21:21. Pushed by davidedmundson into branch 'Plasma/5.22'. Init ShellCorona after KDBusService ShellCorona is created before KDBusService which registers the name. This causes a problem as we register global shortcuts before plasmashell --replace has kiled the old application, which in turn deregisters everything. We want everything before KDBusService to be as light as possible. Moving ShellCorona construction is not trivial as some argument parsing uses that. (cherry picked from commit 9b9b6e5d9bb7308ea47b99eac4044517a8a80ee4) M +4 -1 shell/main.cpp M +3 -0 shell/shellcorona.cpp M +1 -0 shell/shellcorona.h https://invent.kde.org/plasma/plasma-workspace/commit/2a67a010677323a0ec2569510207dbd34031b816
*** Bug 438663 has been marked as a duplicate of this bug. ***
*** Bug 439019 has been marked as a duplicate of this bug. ***
Can reproduce again. SOFTWARE/OS VERSIONS Operating System: KDE neon 5.26 KDE Plasma Version: 5.26.5 KDE Frameworks Version: 5.102.0 Qt Version: 5.15.8 Graphics Platform: X11
This is a fairly old bug report and the code has changed a lot since it was reported. There's a very good chance the issue you're experiencing is caused by something else, even if the outward symptoms look and feel the same. Can you open a new bug report please? Thank you!