Hey, there’s two different namespaces in the dconf settings steering gnome keyboard shortcuts, namely:
what’s the difference?
Do they have different (but overlapping) command sets?
which one has priority?
I’m having a small trouble here because there’s seemingly some redundancy and my settings sometimes get overrided by that set in the other namespace.
Thanks!
Looks like gnome.shell.keybindings have priority, which makes sense as the setting is more specific than the general wm setting.
But there is a big problem in the fact that default values with higher priority override user set values with lower priority.
I set desktop.wm.keybindings because then my configuration is slight bit more portable. But then the gnome.shell.keybindings settings with the default values overrides my setting. This is inconvenient as I do not touch those settings (nothing in dconf dump /org/gnome/shell).
Any solution that doesn’t involve setting many of the settings twice?
org.gnome.desktop.wm.keybindings was added when porting the old (GNOME 2) metacity GConf schema to GSettings/dconf. It’s in a shared location so that both mutter and metacity can share the same settings.
In hindsight, that decision was a bit silly(*). Switching between mutter/gnome-shell and metacity was never common, it’s basically what a handful of gnome-shell developers were doing before GNOME 3.0. But it’s also not so bad that it’s worth changing.
(*) The patch has my name on it, so I’m allowed to say that
Other schema general live in the module that implements the actions:
org.gnome.mutter.keybindings (added after the fork from metacity, so not shared)org.gnome.mutter.wayland.keybindings (same, but for wayland-specific shortcuts)org.gnome.shell.keybindingsorg.gnome.settings-daemon.plugins.media-keysNo. That’s regardless of whether “command set” refers to the actions (“maximize window”, “toggle overview”, …) or default shortcuts (“super+tab”, “super+a”, …)
There is no explicit priority.
Settings’ keyboard panel checks for conflicts when customizing shortcuts, and help resolving them (either not set the new shortcut, or unset the old one).
But when setting shortcuts by other means, it’s possble to create conflicting configurations. In that case, trying to grab a key combo that was already grabbed will fail.
The order in which keys are grabbed depends on implementation details of GHashTable and should be considered random/undefined.
No. If you don’t use Settings with its conflict resolution, then you are responsible for resolving conflicts yourself.
Thanks for an excellent answer!
I’ll stick with the redundancy then, as it’s simplest for now. Luckily I’m setting all of the options through nix, so there’s definitely room for programmatic conflict resolution (I bet people have done this already, but haven’t found anything quickly).
This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.