Bug 498683 - Shortcuts KCM shows multiple "System Settings" entries
Summary: Shortcuts KCM shows multiple "System Settings" entries
Status: RESOLVED FIXED
Alias: None
Product: systemsettings
Classification: Applications
Component: kcm_keys (show other bugs)
Version: 6.2.5
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-01-15 09:48 UTC by Raphael Kubo da Costa
Modified: 2025-01-21 23:04 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Settings 1 (173.41 KB, image/png)
2025-01-15 09:48 UTC, Raphael Kubo da Costa
Details
Settings 2 (115.15 KB, image/png)
2025-01-15 09:49 UTC, Raphael Kubo da Costa
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Raphael Kubo da Costa 2025-01-15 09:48:46 UTC
Created attachment 177374 [details]
Settings 1

See the attached screenshots.

The global shortcuts for KWin effects are all grouped under a System Settings entry, which is different from the second System Settings entry that has entries from other KCMs (like kscreen, screenlocker and users).

The .desktop files all seem to be generated via kcmutils_generate_desktop_file(), which sets X-KDE-AliasFor=systemsettings, but it is unclear why the entries are not all grouped together. Not following X-KDE-AliasFor and having separate shortcut settings for kwin, kscreen etc would be even better.
Comment 1 Raphael Kubo da Costa 2025-01-15 09:49:30 UTC
Created attachment 177375 [details]
Settings 2
Comment 2 David Redondo 2025-01-15 14:18:16 UTC
The second one is the "real" systemsettings. Not sure how your kwin shortcuts ended up that way
Comment 3 Nate Graham 2025-01-15 18:14:31 UTC
Yeah the first one appears to be a mis-named "KWin" group.

Does this reproduce in a new clean user account, Raphael?
Comment 4 Raphael Kubo da Costa 2025-01-19 10:25:02 UTC
Hmm, I ran `kbuildsycoca6` and logged in again and this bug was gone -- there's just one System Settings entry and I now have a "KWin" group under "System Services". This is an old installation so something must've screwed up ~/.config/kglobalshortcutsrc at some point.

With that said, I also tested this on a Neon image and noticed that there were two "KWin" components, one of which should have been called "Session Management". This global shortcuts code is a bit fragile, with pieces in kxmlgui, kglobalaccel, kglobalacceld and plasma-workspace, but I think I have a fix for this specific case and will piggyback on this bug in the commit message.
Comment 5 Bug Janitor Service 2025-01-19 10:47:06 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/255
Comment 6 Raphael Kubo da Costa 2025-01-21 23:02:45 UTC
Git commit 702a8fe3e75b04c376ed2db95ed39b0b29a9ff17 by Raphael Kubo da Costa.
Committed on 21/01/2025 at 22:57.
Pushed by rkcosta into branch 'master'.

ksldapp: Set componentDisplayName property for global Lock Session action

This is used by kglobalacceld as the "friendly name" of a given component,
which kcm_keys then uses as a name in the Shortcuts KCM list.

When not set, the application name is used. Although different plugins and
libraries (e.g. plasma-workspace's startkde/session-shortcuts and
KScreenLockerSettings here) register global shortcuts for the "ksmserver"
component with the "Session Management" display name, KSldApp::initialize()
might be the first to register a ksmserver global shortcut.

When testing the latest Neon stable release (neon-user-20250119-0743) with a
new installation, kwin_wayland would often be the first to call
KSldApp::initialize(), so we would end up with a new component called
"ksmserver" with a friendly name of "KWin".

In practice, we would end up with two KWin components in the Shortcuts KCM,
the real one and the one that should be called "Session Management", which
has "Lock Session", "Log Out" etc.

M  +3    -0    ksldapp.cpp

https://invent.kde.org/plasma/kscreenlocker/-/commit/702a8fe3e75b04c376ed2db95ed39b0b29a9ff17
Comment 7 Raphael Kubo da Costa 2025-01-21 23:04:41 UTC
I'm closing this bug; as mentioned in the MR above, after a quick look at LXR and this was the only occurrence I could find of a missing component display name; the others were applications (in which case it made sense for KActionCollection to use the application name) or places where "componentDisplayName" was already being set.

I'd be glad to fix other occurrences if someone can finds some more.