GNOME Bugzilla – Bug 666513
meta_display_add_keybinding doesn't allow the same keybinding name under a different schema
Last modified: 2021-07-05 13:50:02 UTC
meta_display_add_keybinding will spew an error (and fail) when you try to add a keybinding with a name that has already been added. In the case of bindings with the same name under two different schemas (e.g two different gnome-shell extensions), this seems like it should be perfectly valid. I originally filed this under "meta_display_remove_keybinding should take a `schema` argument", before I realised why it doesn't need to. But if this is fixed, it will need to.
(In reply to comment #0) > this seems like it should be perfectly valid. Does it? It's definitively possible to make it technically valid, but I don't think it makes much sense. An action like "maximize" has a defined meaning and the question "but do you mean org.gnome.mutter maximize or org.gnome.shell maximize?" does not make sense at all.
I thought the entire purpose of different schemas was to allow mutually unaware code to coexist without having to worry about potential clashes. By all means, if you are overriding "maximize" then you should know that and take over the official binding (whether it be mutter or gnome shell, presumably there is only one). But for extensions, the last thing you want to have to do is make sure you have picked names that are unique enough to your extension that _no other extension_ will pick the same names - otherwise your extension will randomly fail depending on what other extensions the user has installed / activated. For example, I have just invented the following keybindings for shellshape (in my own schema): name="tile-current-window" name="untile-current-window" name="adjust-splits-to-fit" name="increase-main-window-count" name="decrease-main-window-count" name="next-window" name="prev-window" name="rotate-current-window" name="rotate-current-window-reverse" name="focus-main-window" name="swap-current-window-with-main" name="set-layout-tiled-horizontal" name="set-layout-floating" name="set-layout-tiled-vertical" name="increase-main-split" name="decrease-main-split" name="increase-minor-split" name="decrease-minor-split" name="increase-main-size" name="decrease-main-size" name="increase-minor-size" name="decrease-minor-size" name="increase-size" name="decrease-size" name="switch-workspace-up" name="switch-workspace-down" name="move-window-workspace-up" name="move-window-workspace-down" name="toggle-maximize" name="unminimize-last-window" That's 30 keybinding names that no other extension can safely use now. And many of them could well be valid names for other extension purposes (perhaps "increase-size" could be used in to an extension for adjusting font sizes or zooming the whole desktop, for example). Aside: I know some of them duplicate mutter functionality. This is so users get the shellshape-default keybindings for these actions without having to manually reconfigure their keybindings (and it allows the mutter keybindings fo the same operations still work as well, which is difficult to configure with the GUI).
Could we at least (before 3.4 is released) add a `schema` argument to meta_display_remove_keybinding that goes unused for now? That way at least it wouldn't require an API change to fix this bug.
I'd say that 'increase-size' is just too generic a name, and you should use 'increase-window-size'. Then that other extension can use 'increase-font-size' without a clash.
@Matthias: by that logic, I should really namespace my names _properly_, and not just rely on "reasonably unique" names. In which case I'd end up with keys like `or.gnome.shell.extensions.net.gfxmonk.shellshape.keybindings.net_gfxmonk_shellshape_increase_size`, just to be certain. Is there any benefit to specifically disregarding the namespace (schema)? The only outcomes I can see are: 1) it might fail, telling an author they should override the canonical keybinding instead 2) it might fail, even when the extension author should _not_ have used an existing key (the names just happened to collide) (1) seems only slightly useful (extensions authors should already be aware of this), while (2) will have the effect of a broken extension, potentially on an end-user's machine who has no idea what's going on and no way to fix it. And in order to fix it, one or more extension authors would have to change their schema, breaking any customisations that used / relied on that schema.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/mutter/-/issues/ Thank you for your understanding and your help.