Description of problem: gnome-shell only switches workspaces on the primary monitor regardless of the setting of the workspaces_only_on_primary switch. Version-Release number of selected component (if applicable): gnome-shell-3.3.2-2.fc17.x86_64 mutter-3.3.2-2.fc17.x86_64 How reproducible: always Steps to Reproduce: 1. Switch workspaces 2. Note that only the primary monitor has changed and half of the screen space you used to have is no longer available as it once was 3. Actual results: Only primary monitor switches between workspaces Expected results: All monitors switch when workspaces_only_on_primary is reset Additional info: It also forgot all of my key bindings to switch between workspaces, which is aggravating, but I've kind of gotten used to that and was able to restore them.
Any chance that anybody is reading this? It's been a while, and this is a really annoying regression. To make it worse, it now seems impossible to turn off "edge tiling" too, which is even worse.
In GNOME 3.3, window management preferences move to GSettings - they were one of the only GConf holdouts in GNOME 3.0/3.2: gsettings set org.gnome.org workspaces-only-on-primary false maybe you are trying to set the GConf key? workspaces-only-on-primary should actually work better in 3.3.3 than it did in 3.0 and 3.2 - changes on the fly are taken into account, and some problems with the GNOME Shell UI are fixed https://bugzilla.gnome.org/show_bug.cgi?id=664853 https://bugzilla.gnome.org/show_bug.cgi?id=652580
That command totally fails, but, after some digging, I found: gsettings set org.gnome.shell.overrides workspaces-only-on-primary false ...and that worked. The edge tiling abomination was disabled in a similar way. A couple of obvious questions come from all of this: - How the hell are GNOME users supposed to know how to tweak their settings? There's dconf-editor, gconf-editor, and gsettings, each of which seems to tweak a different database, and no guidance as to which one should actually be used. - Why the hell does GNOME have to forget all of these settings on a regular basis, forcing users to figure out the new way to restore their desktop to a usable state? Sorry if I sound grumpy, but this is becoming increasingly painful.
Sorry about the incorrect command line - was working largely from memory. * dconf-editor and gsettings control the same database - "DConf" is the storage API, GSettings the API above it in GLib. I tend to work from the gsettings command line, but dconf-editor gets you to the same place. * We moved to GConf for GNOME 1.4 in 2001, so the switch to GSettings/DConf for GNOME 3.0 in 2011 is certainly not a regular thing. * Almost all of GNOME was moved to GSettings for GNOME 3.0, but Mutter and Metacity (which share many settings) were not. So this move in 3.2, though I appreciate that it is annoying, is getting rid of some inconsistency. * There's some infrastructure for GConf => GSettings key migration, though I don't know the details - we may just not have added the necessary files yet - GNOME 3.3 is still at an fairly early stage.
Thanks for the info, and apologies again if I came off overly grumpy. As a mere kernel developer, I have to say that I find the whole GNOME settings mechanism to be obscure and hard to understand. It might help others who are as easily confused as me to take the items out of gconf-editor - or, even better, to put a note in there. Meanwhile, this bug can probably be deemed NOTABUG and closed.
The upstream issue has been fixed and will be part of the next unstable release.