Bug 484682

Summary: Since 6.0.3, global shortcuts do not persist settings across sessions and behave erratically
Product: [Applications] systemsettings Reporter: Naxdy <xnaxdy>
Component: kcm_keysAssignee: Plasma Bugs List <plasma-bugs>
Status: RESOLVED FIXED    
Severity: normal CC: alois1, alphaLimaTango, bugreporter42, bugs.kde, chermnykh2001, fanzhuyifan, kde, kinneyanick, kurnevsky, nate, nicolas.fella, sites+kdebugs
Priority: NOR Keywords: regression
Version: 6.0.3   
Target Milestone: ---   
Platform: NixOS   
OS: Linux   
Latest Commit: Version Fixed In: 6.0.5
Sentry Crash Report:

Description Naxdy 2024-03-28 19:38:26 UTC
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.
Comment 1 Nicolas Fella 2024-03-28 22:34:43 UTC
Can you attach your .config/kglobalshortcutsrc?
Comment 2 fanzhuyifan 2024-03-28 22:43:23 UTC
Waiting for .config/kglobalshortcutsrc
Comment 3 Nicolas Fella 2024-03-28 22:48:45 UTC
There haven't been many changes in kglobalaccel between .2 and .3. https://invent.kde.org/plasma/kglobalacceld/-/commit/cca0bbeb4600a6b06c821044b924c4b8ab53059c looks the most relevant
Comment 4 Naxdy 2024-03-29 08:28:23 UTC
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?
Comment 5 Naxdy 2024-03-29 09:21:06 UTC
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.
Comment 6 Naxdy 2024-03-29 10:02:42 UTC
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)
Comment 7 fanzhuyifan 2024-03-29 15:51:22 UTC
On Nixos, do you know where the desktop file for spectacle is placed?
Comment 8 Naxdy 2024-03-29 15:55:31 UTC
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/...
Comment 9 alphaLimaTango 2024-03-31 01:50:13 UTC
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.
Comment 10 Nicolas Fella 2024-04-03 11:01:31 UTC
(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.
Comment 11 Dmitrii Chermnykh 2024-04-22 09:34:26 UTC
*** Bug 484884 has been marked as a duplicate of this bug. ***
Comment 12 Dmitrii Chermnykh 2024-04-22 16:16:26 UTC
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)
Comment 13 Dmitrii Chermnykh 2024-04-22 16:32:22 UTC
(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
Comment 14 bugreporter42 2024-05-03 14:16:33 UTC
Me too. Global shortcuts initially work, but after a reboot they likely disappear/stop working.
Comment 15 bugreporter42 2024-05-03 14:39:25 UTC
(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.
Comment 16 Nicholas Kinney 2024-05-15 02:24:54 UTC
(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.
Comment 17 Nicolas Fella 2024-05-20 11:20:05 UTC
Fixed with https://invent.kde.org/plasma/kglobalacceld/-/merge_requests/49