SUMMARY From 6.0.2 -> 6.0.3, global shortcut functionality has more or less broken down on my systems, at least when it comes to configuring them. I noticed that, at least for Spectacle, the shortcuts are reset to their factory defaults upon every single sign in. Additionally, modifying a shortcut may (or may not) lead to two Spectacles appearing in system settings (see attachment). STEPS TO REPRODUCE 1. Log in to Plasma 6.0.3 session (Wayland) 2. Open System Settings 3. Navigate to Input & Output -> Keyboard -> Shortcuts 4. Select Spectacle 5. Choose a new custom shortcut for "Capture Rectangular Region" (I used Meta+Shift+S and reassigned the default shortcut, but I've observed the same behavior with different combinations) 6. Apply 7. Attempt to use the newly (re-)defined shortcut immediately. OBSERVED RESULT The (re-)defined shortcut may or may not work. Signing out and signing in again sees all shortcuts reset to factory default. After relogging and opening System Settings shortcuts, there may be (or may not be) two entries for Spectacle present. EXPECTED RESULT The (re-)defined shortcut is assigned immediately, and continues to function between sessions. SOFTWARE/OS VERSIONS Linux/KDE Plasma: NixOS (available in About System) KDE Plasma Version: 6.0.3 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.3 ADDITIONAL INFORMATION This could be an upstream bug in NixOS, well at least it feels like the sort of thing that could be introduced there, but I couldn't see any significant changes from the nixpkgs side of things. Would be great if someone on a different distro could confirm this issue.
Can you attach your .config/kglobalshortcutsrc?
Waiting for .config/kglobalshortcutsrc
There haven't been many changes in kglobalaccel between .2 and .3. https://invent.kde.org/plasma/kglobalacceld/-/commit/cca0bbeb4600a6b06c821044b924c4b8ab53059c looks the most relevant
This happens regardless of the contents of ~/.config/kglobalshortcutsrc Before my last reproduction, I nuked that file completely and had it be regenerated by the system, same result. Also reproduced it on a system that was completely clean, same result. (also NixOS FYI) FWIW: aloisw from the NixOS Matrix suspects this MR to be the likely culprit: https://invent.kde.org/plasma/kglobalacceld/-/merge_requests/47 I'm inclined to agree, since on NixOS, the actual location of .desktop files is ever changing, so I don't think this logic can be safely applied here. I think the most sensible thing in this situation would be for NixOS to manually patch out this behavior to make it fit the distro's needs, but what is your opinion?
I've been able to confirm that simply commenting out this line ( https://invent.kde.org/plasma/kglobalacceld/-/merge_requests/47/diffs?view=inline#014186ddf2dd1aa75709115400e25e06ba6e2d47_260_262 ) fixes the issues on NixOS. Both shortcuts resetting and the glitchy behavior of duplicate entries being present. It seems that either component->uniqueName() is not correctly resolving to the .desktop file's name, or that QStandardPaths::locate(QStandardPaths::GenericDataLocation, QLatin1String("kglobalaccel/") + component->uniqueName()).isEmpty() is not looking in the right place for desktop files.
Additional info: When attempting to delete an application from System Settings' shortcuts page, the "global shortcuts service" dies, and I am left with the following in my journal: Mar 29 10:23:24 nxwiwin systemsettings[6641]: org.kde.kcm_keys: "Error while calling cleanUp of componentorg.kde.spectacle.desktop" Mar 29 10:23:24 nxwiwin systemsettings[6641]: org.kde.kcm_keys: "org.freedesktop.DBus.Error.UnknownObject" "No such object path '/component/org_kde_spectacle_desktop'" (Wayland FYI)
On Nixos, do you know where the desktop file for spectacle is placed?
It varies. NixOS uses the XDG_DATA_DIRS env variable to specify where to look for "stuff". On my system, this evaluates to a rather long list of paths. Notable inclusions are these two: /etc/profiles/per-user/naxdy/share and /run/current-system/sw/share These two house symlinks to files from packages that are installed for my user, and system wide respectively. As for Spectacle's desktop file, a symlink is placed in /run/current-system/sw/share/applications/org.kde.spectacle.desktop (since it's installed system-wide), but the actual path of the desktop file is /nix/store/pxwfzb8l76scjk7pcxi69ncxypbij0d3-spectacle-24.02.1/share/applications/org.kde.spectacle.desktop The actual path is changing very often, hence the symlink to /run/current-system/...
I updated to KDE Plasma 6 in Artix and all of my shortcuts are broken too. They show up as "Custom Shortcuts Service" with no icon in System Settings, and there's no obvious reason as to why they're all broken.
(In reply to Naxdy from comment #5) > I've been able to confirm that simply commenting out this line ( > https://invent.kde.org/plasma/kglobalacceld/-/merge_requests/47/ > diffs?view=inline#014186ddf2dd1aa75709115400e25e06ba6e2d47_260_262 ) fixes > the issues on NixOS. Both shortcuts resetting and the glitchy behavior of > duplicate entries being present. > > It seems that either component->uniqueName() is not correctly resolving to > the .desktop file's name, or that Can you tell what the value of component->uniqueName() is? > QStandardPaths::locate(QStandardPaths::GenericDataLocation, > QLatin1String("kglobalaccel/") + component->uniqueName()).isEmpty() > > is not looking in the right place for desktop files.
*** Bug 484884 has been marked as a duplicate of this bug. ***
On NixOS: If I do "edit application" in plasma menu it shows the location of .desktop file as "/nix/store/.../share/applications", but if I try to find the .desktop item in XDG_DATA_DIRS it resolves into "/run/current-system/sw/share": fd spectacle.desktop $(echo $XDG_DATA_DIRS | sd ':' ' ') [fd error]: Search path '/home/chermnyx/.local/share/flatpak/exports/share' is not a directory. [fd error]: Search path '/home/chermnyx/.nix-profile/share' is not a directory. [fd error]: Search path '/nix/profile/share' is not a directory. [fd error]: Search path '/home/chermnyx/.local/state/nix/profile/share' is not a directory. [fd error]: Search path '/nix/var/nix/profiles/default/share' is not a directory. /run/current-system/sw/share/applications/org.kde.spectacle.desktop /run/current-system/sw/share/kglobalaccel/org.kde.spectacle.desktop It seems that the symlinks are getting resolved somewhere and plasma gets confused by nix store paths It also makes any existing .desktop entry cache invalid on each nixos system rebuild (nixos does `rm -fv $HOME/.cache/ksycoca*` as a workaround: https://github.com/NixOS/nixpkgs/pull/292748/files)
(In reply to Nicolas Fella from comment #10) > (In reply to Naxdy from comment #5) > > I've been able to confirm that simply commenting out this line ( > > https://invent.kde.org/plasma/kglobalacceld/-/merge_requests/47/ > > diffs?view=inline#014186ddf2dd1aa75709115400e25e06ba6e2d47_260_262 ) fixes > > the issues on NixOS. Both shortcuts resetting and the glitchy behavior of > > duplicate entries being present. > > > > It seems that either component->uniqueName() is not correctly resolving to > > the .desktop file's name, or that > > Can you tell what the value of component->uniqueName() is? > > > QStandardPaths::locate(QStandardPaths::GenericDataLocation, > > QLatin1String("kglobalaccel/") + component->uniqueName()).isEmpty() > > > > is not looking in the right place for desktop files. For me in PyQT it resolves to the correct file and qdbus shows that `component->uniqueName()` for spectacle is `org.kde.spectacle.desktop` In [17]: QStandardPaths.locate(QStandardPaths.StandardLocation.GenericDataLocation, "kglobalaccel/org.kde.spectacle.desktop") Out[17]: '/run/current-system/sw/share/kglobalaccel/org.kde.spectacle.desktop' qdbus org.kde.kglobalaccel /component/org_kde_spectacle_desktop org.kde.kglobalaccel.Component.uniqueName org.kde.spectacle.desktop
Me too. Global shortcuts initially work, but after a reboot they likely disappear/stop working.
(In reply to bugreporter42 from comment #14) > Me too. Global shortcuts initially work, but after a reboot they likely > disappear/stop working. That's been broken since Arch switched to Plasma 6.
(In reply to bugreporter42 from comment #15) > (In reply to bugreporter42 from comment #14) > > Me too. Global shortcuts initially work, but after a reboot they likely > > disappear/stop working. > > That's been broken since Arch switched to Plasma 6. Definitely not correct, I have set my archive to the day before 6.0.3 launched and confirmed the behavior was not present before the upgrade.
Fixed with https://invent.kde.org/plasma/kglobalacceld/-/merge_requests/49