https://bugs.kde.org/show_bug.cgi?id=524386
--- Comment #2 from [email protected] --- (In reply to Akseli Lahtinen from comment #1) > Can't reproduce > > Operating System: KDE Linux 2026-08-13 > KDE Plasma Version: 6.7.80 > KDE Frameworks Version: 6.30.0 > Qt Version: 6.11.1 > Kernel Version: 7.1.8-arch1-3 (64-bit) > Graphics Platform: Wayland > Processors: 12 × AMD Ryzen 5 3600 6-Core Processor > Memory: 16 GiB of RAM (15.5 GiB usable) > Graphics Processor: AMD Radeon RX 6600 Sorry, my original report didn't describe some details precisely enough, which may have caused a misunderstanding. Here is what I actually observe: Steps to reproduce: 1. Make sure the [services][org.kde.spectacle.desktop] section of ~/.config/kglobalshortcutsrc has all 10 entries (including CurrentMonitorScreenShot=none and OpenWithoutScreenshot=none); 2. Reboot. At this point the file still contains all 10 entries; 3. Press PrintScreen to take a screenshot once; 4. After the screenshot, check the file: the CurrentMonitorScreenShot and OpenWithoutScreenshot lines are gone, only 8 entries remain. 5. Taking more screenshots in the same session no longer changes the file (only the first screenshot in a session triggers the change). The key point is that how you deal with the two "disappearing" lines leads to two different loops: - Case A: if I manually add the two lines back after step 4, then reboot and press PrintScreen, they disappear again — the file never settles; - Case B: if I leave them alone (keep them absent), reboot and press PrintScreen, they are automatically written back (as =none) instead. In other words, after every "reboot + first screenshot" these two lines flip between present and absent, which is why my git-tracked ~/.config keeps churning on every reboot. My original report saying the file was "rewritten at every login/logout" was inaccurate: the actual trigger is not login/logout itself, but the moment Spectacle is first started in a session (pressing PrintScreen, which activates it over DBus). If I reboot and don't press PrintScreen, the file doesn't change. Also worth noting: whether these two lines exist has no impact on functionality (both are =none); this is purely a config-file churn problem. --- About when the problem started and its cause: I used an AI assistant to check my local upgrade log (pacman.log) and the git history of my config file. The AI's findings are as follows: 1. When it started The problem began around June this year, when Arch Linux upgraded my Plasma from 6.6.x to 6.7.0 (2026-06-19, kglobalacceld 6.6.5 -> 6.7.0). Before that, those two lines in my config file had always been empty values (CurrentMonitorScreenShot=); after 6.7.0 they became =none and the add/remove churn described above started. 2. Root cause (based on reading the 6.7.4 sources) 1) In org.kde.spectacle.desktop, the two Desktop Actions CurrentMonitorScreenShot and OpenWithoutScreenshot do not declare X-KDE-Shortcuts. 2) When kglobalacceld loads a desktop file, it parses a missing default shortcut as "a set containing one empty QKeySequence"; whereas Spectacle registers these two actions at startup with a genuinely empty set. The two representations are not equal. 3) So every time Spectacle first starts in a session (DBus activation via PrintScreen) and registers its default shortcuts, kglobalacceld concludes "the default changed", updates the in-memory default, and schedules a config write. 4) On write, the section is cleared and rewritten; each entry's fate depends on comparing its "current keys" with its "default keys": - if the two lines are absent from the file, the parsed state differs from the default, so they are written back as =none (Case B: they come back); - if the two lines are =none, the comparison is equal, the entries are treated as "equal to default, nothing to persist" and reverted away (Case A: they disappear). This creates the endless flip on every "reboot + first screenshot". 5) Within the same session Spectacle (a resident --dbus process) doesn't register again, which is why only the first screenshot triggers the change. 3. Is Spectacle itself at fault? >From the investigation, Spectacle's code and desktop file are both fine: - not declaring X-KDE-Shortcuts for these two actions is a legitimate way to say "this action has no default shortcut"; - registering them with an empty shortcut list at startup is standard API usage, done so that they show up in System Settings -> Shortcuts for users to assign keys. The other 7 actions register defaults identical to the desktop file and never trigger any change, which confirms Spectacle's usage is correct; - the root cause is on the kglobalacceld side: the same "no shortcut" semantics is represented by two unequal internal values depending on whether it comes from parsing a desktop file or from an application registration. Any app that "has desktop actions without X-KDE-Shortcuts + registers them at runtime with an empty list" would hit this; Spectacle is just the most common such app; - the upstream fix also landed entirely in kglobalacceld, with no Spectacle changes. So this bug might be better reassigned to the kglobalacceld component. 4. Current status and suggested fix The upstream kglobalacceld repository already fixed this incidentally in commit b39cf786 (2026-06-05, "Normalize various empty shortcut formats to empty set"), which unifies all "empty shortcut" representations to the empty set. That commit is in Plasma 6.7.80 (development version), which explains why you cannot reproduce it on 6.7.80. However the stable Plasma/6.7 branch does not contain it: as of the latest 6.7.5 release (2026-08-04) it still hasn't been backported, so the problem persists on stable. Notably, the preceding commit of the same series, 92ca7f36 (2026-05-08, "Serialize empty QKeySequence object as none"), did land in 6.7.0 — it is precisely this "half of the series merged" state that produces the behavior seen on 6.7.x stable. Suggestions: - backport b39cf786 (or an equivalent normalization fix) to the Plasma/6.7 stable branch; - or fix the comparison logic separately, so that registering with an empty default no longer differs from the parsed "no default declared" state and triggers a rewrite. For reference, my environment: Arch Linux, Plasma 6.7.4, Frameworks 6.28.0, Qt 6.11.1, Wayland. -- You are receiving this mail because: You are watching all bug changes.
