Some of you may already know: it has been roughly a week since metacity/mutter switched to GSettings. The fallout has been quite small, so this seems like a good time to sum up the changes which may be of wider interest:
- no more hidden binding_name_list settings – while the System Settings panel still only allows to assign a single keybinding to each action, keybindings are always stored as lists, so it is possible to have multiple bindings per action
- no more custom keybindings in Metacity/Mutter – the Custom Shortcuts section in the Settings panel uses gnome-settings-daemon, there’s no point in having an additional hidden mechanism for the same functionality
- the keybindings to take screenshots have been moved to gnome-settings-daemon – those actions are not window manager related at all, they were provided by Metacity purely due to historic reasons; it is worth mentioning though, as the move breaks the shortcuts in the overview for the time being
- the keybinding to launch a terminal has been removed – I know some people will be pissed off by this, but well … you can define arbitrary keybindings in System Settings, there’s really no point in having a pre-defined (unset-by-default) shortcut for terminals (note how all other pre-defined launchers default to hardware keys found on some keyboards)
- GNOME Shell no longer overrides the theme preference – Metacity has defaulted to ‘Adwaita’ for quite some time, so there’s no good reason to keep a different preference for GNOME Shell; as a consequence, if you changed /desktop/shell/windows/theme, the change will not be migrated automatically – you’ll have to set org.gnome.desktop.wm.preferences theme manually (or just go with the great default theme!)
- the way Mutter handles keybindings has been mostly rewritten – the interesting part of this is that extensions may now use meta_display_add_keybinding() to define their own keybindings
So that’s it for today – if you encounter any issues not mentioned above, feel free to file bugs.
(Hopefully my next blog post will be a bit more interesting …)
While you’re at it, it would be nice to be able to *somehow* edit or at least list custom shortcuts via `gsettings get`… all my current attempts (with git master) resulted in “no such schema” messages.
Unrelated, but yeah, custom keybindings are tricky 🙂
Custom shortcuts use a relocatable schema (org.gnome.settings-daemon.plugins.media-keys.custom-keybinding), so you need to specify a path if you want to edit/list them.
gsettings get org.gnome.settings-daemon.plugins.media-keys custom-keybindingswill give you a list of settings paths (in the form of /org/gnome/settings-daemon/plugins/media-keys/custom-keybindings/customN/). You can then use those paths with the gsettings command, for instancegsettings get org.gnome.settings-daemon.plugins.media-keys.custom-keybinding:/org/gnome/settings-daemon/plugins/media-keys/custom-keybindings/custom0/ bindingNot quite related, but given you mentioned the default theme for metacitiy…:
I am ambivalent with Adwaita. It looks nice with GNOME Shell, but it is not comfortable when using the fallback mode. For instance, the borders are almost invisible but in Shell the shadow helps to catch the border and resize the window. In fallback it requires a lot more precision, and it does not look that nice (because of the lack of shadow).
I wonder if the same theme can coexist in both modes or we need a similar theme (but with customizations) for fallback.
Metacity actually uses a “different” window manager theme – the theme format has been updated to version 3 during the 3.0 cycle, while Metacity keeps using version 2. So some of the theme related quirks in fallback mode could be addressed by giving the “old” theme some love – others (like menus relying on shadows for borders) come from the GTK+ theme though.
To be honest though, I don’t really expect anyone to invest much time in those issues – software rendering in mesa has come a long way, and it’s now good enough to run GNOME Shell without hardware acceleration. While I don’t expect fallback mode to go away immediately as a consequence, I do expect (standalone) Mutter to replace Metacity in the near future.
While you’re at it, it would be /super/ to have working bindings for pushing windows around.
Bindings for Aero-snap-like: snap-resize to left half, right half, bottom half top half. Maybe even quadrants.
Fix the bindings for moving windows to compass corners (nw, sw, ne, etc). This inherited bugs from Metacity. If you try it with Firefox and some other programs, it moves the window· but then as soon as a keystroke is sent to the program it snaps back to the old location.
Yes, expect those soon.
To be honest, that’s a rather obscure feature – the expectation is that someone who actually uses it sends patches 🙂
re 1: really? sweet. What would totally rock is a three-way toggle: half, third, quarter (of the screen).
re 2: Well, they exist, but they are broken.
But I should not say that, the likely result is that they be removed. No?
I would send a patch but I only understand trainstation. While you are having your fingers still juicy from working on this, you could perhaps have a quick look at that as well? I think it must be that some EWMH or whatever flag is not set, so it flips back to where the window thinks it must be. /Or something/
And, it would make sense to have both, move and snap and just move. Some windows just need to be flicked aside. Maybe, say, a calculator window/
Seriously, I use almost all wm bindings available and there are still not enough.
It’s no longer possible to distinguish between 0-9 and KP0-KP9? Is this a bug or intended?
i.e.:
Window manager warning: "KP7" found in configuration database is not a valid value for keybinding "move-to-corner-nw"
Window manager warning: "KP9" found in configuration database is not a valid value for keybinding "move-to-corner-ne"
Window manager warning: "KP1" found in configuration database is not a valid value for keybinding "move-to-corner-sw"
Window manager warning: "KP3" found in configuration database is not a valid value for keybinding "move-to-corner-se"
Window manager warning: "KP8" found in configuration database is not a valid value for keybinding "move-to-side-n"
Window manager warning: "KP2" found in configuration database is not a valid value for keybinding "move-to-side-s"
Window manager warning: "KP6" found in configuration database is not a valid value for keybinding "move-to-side-e"
Window manager warning: "KP4" found in configuration database is not a valid value for keybinding "move-to-side-w"
No changes in that regard – if something broke there, it is an issue with gtk_accelerator_parse().
Ok, will file bug. What irritated me here is that the Keyboard capplet (or however that’s called nowadays) detects keypad presses with simple digits 0-9.
That’s actually not too surprising, given that it uses the same GTK+ functions 🙂
Okay, I typed it wrong (KP_5, not KP5) and B. Nocera gave the hint in the relevant bug report at https://bugzilla.gnome.org/show_bug.cgi?id=664219
Don’t worry, this post was interesting and informing already!
Not that missing shortcut would piss me off, but it is not working at all in latest Fedora by default. https://bugzilla.redhat.com/show_bug.cgi?id=747225
Ugh yeah, that’s unfortunate – I guess we are so desperate to finally kill libgnome that the schema dependency slipped. Hopefully the GSettings migration will be complete in the Fedora 17 timeframe (at least evolution-data-server still needs to be ported).
The workaround you mentioned (Custom shortcut for terminal launch), currently creates terminals that don’t contain the same environment as terminals launched from elsewhere (Shell).
Specifically I noticed that no SSH_AUTH_SOCK is set, so no keyring support in those terminals. Any idea where I should look/file bug?
I figured out this lame workaround for .bashrc
eval $(/usr/bin/gnome-keyring-daemon --start --components=ssh | while read line; do echo export "$line"; done)