GNOME Bugzilla – Bug 671568
(dynamic) workspace count stored in dconf
Last modified: 2012-03-12 08:48:57 UTC
/org/gnome/desktop/wm/preferences/num-workspaces is written to every time the dynamic number of workspaces changes. It's also written to its initial value of 2 at first login. We have the root window property as the official way of advertising the number of available workspaces. Meanwhile, this sort of thing is very much transient state information which will be immediately discarded on next login (when we're forced back to 2 workspaces) so it should definitely not be in GSettings.
(In reply to comment #0) > We have the root window property as the official way of advertising the number > of available workspaces. Meanwhile, this sort of thing is very much transient > state information[...] so it should definitely not be in GSettings. True for gnome-shell, but not for mutter standalone and metacity, where the key is used as a user preference.
*** Bug 659764 has been marked as a duplicate of this bug. ***
The offending writes are a relatively new addition, see bug 613127. I guess we could have an additional 'dynamic-workspaces' setting (defaul: false, overwritten by gnome-shell), and ignore num-workspaces completely when set (I'm not a big fan of use-other-setting "meta"-settings, but other than that the only downside of that approach would be that there'll be demands to support non-dynamic workspaces in the shell)
What would be the downside to just ignoring the existence of this key entirely?
(In reply to comment #4) > What would be the downside to just ignoring the existence of this key entirely? Breaking non-shell users of mutter (meego, standalone mutter), which might be an acceptable downside. If not, a please-ignore-this-key setting as mentioned above (with a nicer name of course) should do the job.
Perhaps instead of a key, we could have an API on mutter informing it that we intend to manage workspaces dynamically and it should ignore GSettings accordingly. gnome-shell could then simply switch that on.
Possibly, though we don't have any precendence for that (while we do for key-backed settings with different default values in mutter and gnome-shell)
Created attachment 209314 [details] [review] prefs: Add dynamic-workspaces setting We currently sync the number of workspaces with the corresponding preference. This is not really useful with GNOME Shell's dynamic handling of workspaces, not least as the setting is effectively ignored. Worse, it will trigger writes to dconf on login, slowing down startup, so add a setting to indicate that workspaces are managed dynamically and really ignore the num-workspaces setting when set. So this is the GSettings approach - an API call would work as well, but then an extension might want to call it to disable it again, so we'd want change notifications (and possibly a signal so gnome-shell can pick up the change as well). GSettings provides all that already, so it makes sense to me to use it ...
Created attachment 209315 [details] [review] main: Add override for dynamic-workspaces key Corresponding shell patch
Created attachment 209317 [details] [review] main: Add (hidden) support for static workspaces The dynamic-workspaces key was introduced to allow us to opt out of writing the num-workspaces setting (which is ignored with the dynamic workspace management anyway), but there'll be some expectations that the setting will have an effect on the UI. It's actually not very hard to support, so here's to the graybeards ...
Review of attachment 209314 [details] [review]: ::: src/org.gnome.mutter.gschema.xml.in @@ +47,3 @@ + <key name="dynamic-workspaces" type="b"> + <default>false</default> Should this not be true by default?
(In reply to comment #11) > Review of attachment 209314 [details] [review]: > > ::: src/org.gnome.mutter.gschema.xml.in > @@ +47,3 @@ > > + <key name="dynamic-workspaces" type="b"> > + <default>false</default> > > Should this not be true by default? No. mutter does not have dynamic workspaces, it behaves exactly like metacity. The follow-up patch adds an overwrite key which will be used instead when running gnome-shell - that key defaults to true.
Review of attachment 209314 [details] [review]: Looks good.
Review of attachment 209315 [details] [review]: Looks good.
Review of attachment 209317 [details] [review]: Makes sense.
Comment on attachment 209314 [details] [review] prefs: Add dynamic-workspaces setting Attachment 209314 [details] pushed as 607dbf0 - prefs: Add dynamic-workspaces setting
Attachment 209315 [details] pushed as 9dcdaf0 - main: Add override for dynamic-workspaces key Attachment 209317 [details] pushed as a197ce6 - main: Add (hidden) support for static workspaces
I know that the mutter patch in attachment 209314 [details] [review] technically broke string freeze - if that is really considered a problem, I can do a follow-up patch to mark the strings in question as non-translatable. I didn't do that in the first place because I expect users that open dconf-editor to have a certain tolerance for untranslated strings (well, and if I hadn't marked the strings for translation, I almost certainly would have forgotten to do so after branching).
Florian, the idea about string freeze is to give time to translators to get the applications fully translated; not marking strings as translatable is adverse to this goal. Please followup on gnome-i18n.