SUMMARY If a distribution or OEM places a kglobalshortcuts file in the path defined in $XDG_CONFIG_DIRS, whether that's in /etc/xdg or otherwise, the settings fail to propogate but get superseded by some kind of built-in hardcoded mechanism as opposed to those that were defined by the distribution or OEM. These settings should simply get written based on whatever the hardcoded defaults are *unless* a default has been defined somewhere in the $XDG_CONFIG_DIRS path (in this case, ~/.config/kdedefaults:/etc/xdg/xdg-plasma:/etc/xdg:/usr/share/kubuntu-default-settings/kf5-settings). STEPS TO REPRODUCE 1. Create a /etc/xdg/kglobalshortcutsrc file containing the following: [kwin] Decrease Opacity=Meta+_,,Decrease Opacity of Active Window by 5 % Increase Opacity=Meta++,,Increase Opacity of Active Window by 5 % 2. Create a new user. 3. Login as new user. 4. Open Dolphin. 5. Attempt to decrease and increase opacity with Meta-Shift-+ or Meta-Shift-=. OBSERVED RESULT Shortcut keys have no effect. Corresponding setting in System Settings > Shortcuts > Shortcuts > KWin shows "No active shortcuts. EXPECTED RESULT Shortcut keys should change opacity of the active window and be set to do so by default. This should be able to be verified via System Settings > Shortcuts > Shortcuts > KWin. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 22.04 (available in About System) KDE Plasma Version: 5.24.6 KDE Frameworks Version: 5.95 Qt Version: 5.15.3 ADDITIONAL INFORMATION Without a way for distributions and OEMs to set hardware or distribution-unique shortcuts, this limits the customization capabilities of KDE Plasma to be custom pre-configured.
The relevant code is https://invent.kde.org/frameworks/kglobalaccel/-/blob/master/src/runtime/globalshortcutsregistry.cpp#L78 It explicitly passes KConfig::SimpleConfig, which means ignoring system-wide config files. This suggests it was done intentionally, but I can't find anything on why this was done this way
Seems like an oversight to me TBH.
There may be a second issue here; my ~/.config/kglobalaccelrc file has entries for all shortcuts written to it, even those with empty shortcuts. So for example my file has: Decrease Opacity=none,,Decrease Opacity of Active Window by 5 % Increase Opacity=none,,Increase Opacity of Active Window by 5 % This will override any default settings at a lower level because user settings take precedence over systemwide settings.
(In reply to Nate Graham from comment #3) > There may be a second issue here; my ~/.config/kglobalaccelrc file has > entries for all shortcuts written to it, even those with empty shortcuts. So > for example my file has: > > Decrease Opacity=none,,Decrease Opacity of Active Window by 5 % > Increase Opacity=none,,Increase Opacity of Active Window by 5 % > > This will override any default settings at a lower level because user > settings take precedence over systemwide settings. If ${setting}=none, shouldn't it look for a setting up the path until it finds one to fill the gap? Seems like if it's writing that, it would prevent any default from being configured ever.
yeah, kglobalshortcutsrc behaves somehow different to other config files, which makes me think that the flag is there for a reason and simply removing it is not the answer here
(In reply to Erich Eickmeyer from comment #4) > If ${setting}=none, shouldn't it look for a setting up the path until it > finds one to fill the gap? If the key is there with any value (even an explicit "none" value), it will override a key set at a lower level. > Seems like if it's writing that, it would prevent > any default from being configured ever. Looks like that's the case, yeah. I was randomly touching the code for this recently so I may be able to fix it
Urgh, or maybe not. I think it might be too complicated for me. Regardless, I think the problem here is that the default shortcuts are all defined in code, in useractions.cpp, rather than using kconfig at all. Probably needs to be ported to KConfigXT. Also, in that file we do `KGlobalAccel::self()->setDefaultShortcut()` as well as `KGlobalAccel::self()->setShortcut()` which seems wrong and unnecessary.
Is this actually specific to kwin or does it affect all shortcuts?
Looks like it affects shortcuts not set by KWin too, so I guess it is (at least primarily) a problem in kglobalaccel.
The problem here is somewhat fundamental to the way kglobalaccel works. Therefore I'm very hesitant to just remove the SimpleConfig flag hoping it will fix everything. When a program registers a global shortcut it does that by calling e.g. KGlobalAccel::self()->setGlobalShortcut(). That will register the shortcut and its associated metadata (internal and user-facing name etc) with klgobalacceld. kglobalacceld then saves that information to kglobalshortcutsrc and loads it again on the next start. Any user modifications are also saved to kglobalshortcutsrc. This causes a behavior of kglobalshortcutsrc that is very different to typical config files. Usually when you never changed any particular setting the relevant file in ~/.config is empty and system-wide or buildin defaults apply. But here you will find that .config/kglobalshortcutsrc is always populated with stuff, even if you never changed anything. The current approacj is quite messy and causes problems (such as this). There is the idea of making shortcut definition more declarative by using per-component desktop files (see https://phabricator.kde.org/T12063). This could probably also help with enabling distro customization like you are asking for
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kglobalaccel/-/merge_requests/56
*** Bug 461583 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kglobalacceld/-/merge_requests/8
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kglobalacceld/-/merge_requests/9
Git commit 316ce3f9b42bfe9ea9d5f44cd37a452d2e0b71e8 by Nicolas Fella. Committed on 22/08/2023 at 00:19. Pushed by nicolasfella into branch 'master'. Only store actual changes in config file for service shortcuts Currently we store the full information for every shortcut in kglobalshortcutsrc. These are internal name, user-facing name, current shortcut, and default shortcut. This has several problems: It behaves differently to how config files usually work, which is only storing non-default information. We read the user-facing name from the original source once and then only consider what we saved in the config file. This means when the original name changes (e.g. because a translation was added) we never update what we display. Distributions/administrators can't supply changes to the defaults via the usual way The only piece of information that is changeable for the user is the current shortcut. Store that in the config file, but only if it is not the default value The rest of the information (user-facing name and default shortcut) is read from the desktop file. This is only done for desktop-file-registered shortcuts. Runtime-registered shortcuts have the same problem, but it's more complicated to fix there, so that's for another day. I expect us to move most if not all runtime shortcuts to desktop-file shortcuts anyway This breaks the config format, so on startup migrate the old data to the new format, in a new group. To not break things for people switching between Plasma 5 and 6 for development don't remove the old data. Once Plasma 6 matures we can consider dropping that data M +5 -0 CMakeLists.txt A +3 -0 autotests/CMakeLists.txt A +309 -0 autotests/kglobalshortcutsrc A +319 -0 autotests/kglobalshortcutsrc.expected A +63 -0 autotests/migrateconfigtest.cpp [License: LGPL(v2.0+)] M +3 -6 src/component.cpp M +6 -3 src/component.h M +1 -0 src/globalshortcutcontext.h M +87 -5 src/globalshortcutsregistry.cpp M +4 -1 src/globalshortcutsregistry.h M +53 -0 src/kserviceactioncomponent.cpp M +2 -1 src/kserviceactioncomponent.h https://invent.kde.org/plasma/kglobalacceld/-/commit/316ce3f9b42bfe9ea9d5f44cd37a452d2e0b71e8