Summary: | Since 6.0.3, global shortcuts do not persist settings across sessions and behave erratically | ||
---|---|---|---|
Product: | [Applications] systemsettings | Reporter: | Naxdy <xnaxdy> |
Component: | kcm_keys | Assignee: | 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
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. |