GNOME Bugzilla – Bug 689763
Tweak dynamic-workspaces based on the mode
Last modified: 2018-01-24 15:06:50 UTC
The proposed replaced for the fallback session will run gnome-shell in a different mode. It will use a tiny extension to disable dynamic-workspaces by default (bug 689739). Therefore StaticWorkspaceTweak should differentiate between the vanilla GNOME Shell mode and the fallback replacement mode (which is yet to be named). An org.gnome.Shell.Mode property was added for this: bug 689300.
Thanks - can you please CC me on any relevant GS bugs too? (although I note and thank you for doing a great job providing patches etc for g-t-t. I'm stuck on Ubuntu 12.04 / GS 3.4 for work and all help tracking master is appreciated)
Created attachment 230882 [details] [review] dont show dynamic workspace switch in 'classic' mode
Can you please test this - do I have to treat the number of workspaces differently?
Works for me. I have a patch to still expose the switch but change the schema underneath it, similar to bug 689358. That way someone can tweak the fallback replacement mode too, if they wanted. I don't have any strong feelings either way. Feel free to use whichever one you think is more appropriate.
Created attachment 230883 [details] [review] Choose the dynamic-workspaces schema based on the session mode
(In reply to comment #4) > Works for me. > > I have a patch to still expose the switch but change the schema underneath it, > similar to bug 689358. That way someone can tweak the fallback replacement mode > too, if they wanted. > > I don't have any strong feelings either way. Feel free to use whichever one you > think is more appropriate. Yours is nicer I think. I thought this whole overrides business was meant to let the shell advance in spite of mutter/metacity. Is it going to be used to do things like this for the forseeable future or will I have to then back out this change because the schema will be shared. What are your and the GS developers thoughts?
(In reply to comment #6) > I thought this whole overrides business was meant to let the shell advance in > spite of mutter/metacity. Is it going to be used to do things like this for the > forseeable future or will I have to then back out this change because the > schema will be shared. I believe org.gnome.Shell.overrides is an artifact of history, but these days elementary OS has a WM called Gala based on Mutter [1]. There have been some proposals to use a separate dconf profile too, plus there is the whole question of whether we should insulate the settings from each mode or not. As of now fmuellner and I (eg., bug 689739) think we should try to insulate the settings, but mclasen is of the opinion that we should not. There are good arguments on either side, so I am not sure what to say. :-) [1] http://www.youtube.com/watch?v=WGMEhSiXx6M
Hmm... now that the patch in bug 689739 has been committed, swapping the schemas appear to be the way to go. Atleast for the time being. :-)
Review of attachment 230882 [details] [review]: nope
Attachment 230883 [details] pushed as d53b518 - Choose the dynamic-workspaces schema based on the session mode
Review of attachment 230883 [details] [review]: Sorry for not chiming in early, I've only just stumbled upon this patch: ::: gtweak/tweaks/tweak_shell.py @@ +207,3 @@ + _shell = GnomeShellFactory().get_shell() + if _shell.mode in ['gdm', 'initial-setup', 'user']: + DYNAMIC_SCHEMA = "org.gnome.shell.overrides" The logic here is wrong - gnome-shell *always* overrides a couple of keys. The 'classic' mode contains an extension that explicitly reverses the override for the 'dynamic-workspaces' key, any mode that does not do that will use the override schema. Of course it doesn't matter in practice for now with 'classic' being the only external mode, but I consider if _shell.mode in ['classic']: DYNAMIC_SCHEMA = "org.gnome.mutter" ... the more correct variant.
(In reply to comment #11) > The logic here is wrong - gnome-shell *always* overrides a couple of keys. The > 'classic' mode contains an extension that explicitly reverses the override for > the 'dynamic-workspaces' key, any mode that does not do that will use the > override schema. > Of course it doesn't matter in practice for now with 'classic' being the only > external mode, but I consider > > if _shell.mode in ['classic']: > DYNAMIC_SCHEMA = "org.gnome.mutter" > ... > > the more correct variant. You are right. I agree with you. However, I wrote it that way to avoid littering the code bases with 'classic' so that if we chose to change the name later, we could do so with lesser changes / breakage.
If we have a fixed number of workspaces - the final thing blocking my move to GNOME 3.x is being able to arrange them in a 2D matrix and switch between them quickly (though I completely appreciate that this is some advanced / 0.05% use-case ;-). Presumably with a fixed number of workspaces this becomes at least theoretically possible - and I was wondering if there was an existing extension that enables that ?
A fixed number of workspaces is supported now (> 3.4 IIRC) by setting dynamic-workspaces = False, and num-workspaces > 0 But, not in a grid.... I'm not aware of a gridded workspace extenson.
https://extensions.gnome.org/extension/484/workspace-grid/ ? Welcome to GNOME 3, Michael
Whoot ! that is sexy - thanks Matthias, will have a play as/when LibO 4.0 release craziness dies down :-)
(In reply to comment #12) > However, I wrote it that way to avoid littering the code bases with 'classic' > so that if we chose to change the name later, we could do so with lesser > changes / breakage. Define a NeckbeardModeName variable once and use that everywhere? In any case, I think the "GNOME Classic" name has had too much public exposure by now to change it at this point, so it's likely what'll stick around :(
Mathias - interesting; I'm struggling with workspace-grid, it appears not to support Gnome 3.8 - and/or it appears to install with no visible errors, both if downloaded and installed via tweak-tool and via the web-interface; nevertheless it appears not to work, and doesn't show up at: https://extensions.gnome.org/local/ either - which is rather curious :-) a shame ...
Florian, Debarshi, whats the recommended way to do this with the new overrides system? Does Comment 11 still hold? Passing this onto Alex
(In reply to comment #19) > > Does Comment 11 still hold? Not really. It is still true that gnome-shell will always override a couple of settings, but classic mode no longer uses extensions to revert some of those but uses a different override schema altogether. See bug 701760.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-tweaks/issues/28.