GNOME Bugzilla – Bug 698593
Move g-i-s to another workspace available
Last modified: 2013-07-18 22:04:44 UTC
Currently it's possible to move g-i-s to another workspace in gnome-shell initial-setup mode. Not sure if this is a bug with that mode or something we should override using org.gnome.desktop.wm.preferences num-workspaces and org.gnome.shell.overrides dynamic-workspaces
I think that would have to be a change to the initial-setup mode in gnome-shell. We could think about shipping that mode definition with gnome-initial-setup, but currently it is part of gnome-shell.
This seems to be a gnome-shell bug, where we don't actually respect hasWorkspaces. I'm working on a patch now.
Created attachment 246921 [details] [review] Fix launching apps / search results in new workspaces by dragging When I landed the new workspace tracker move, I didn't realize there was public API being used by clients here. Add that back.
Created attachment 246922 [details] [review] windowManager: Actually respect hasWorkspaces We've long had the hasWorkspaces property, but it doesn't seem like it was ever used. Implement it so that we don't have workspaces in initial-setup mode.
Review of attachment 246921 [details] [review]: LG.
Review of attachment 246922 [details] [review]: ::: js/ui/windowManager.js @@ +81,3 @@ _init: function(wm) { this._wm = wm; + this._workspaceSettings = new Gio.Settings({ schema: Main.dynamicWorkspacesSchema }); Pointlessly moving code around @@ +93,3 @@ + let tracker = Shell.WindowTracker.get_default(); + if (Main.sessionMode.hasWorkspaces && !this._startupSequenceChangedId) { + this._startupSequenceChangedId = tracker.connect('startup-sequence-changed', Lang.bind(this, this._queueCheckWorkspaces)); You make _queueCheckWorkspaces a no-op when hasWorkspaces is false, you could just rely on that ... @@ +104,3 @@ + this._startupSequenceChangedId = 0; + + tracker.disconnect(this._nWorkspacesChangedId); ... in any case, "tracker" is clearly wrong here @@ -1028,3 @@ if (activeWorkspace != workspace) workspace.activate(global.get_current_time()); - Unrelated whitespace change @@ -1044,3 @@ workspace.activate_with_focus (window, global.get_current_time()); } - Unrelated whitespace change
Comment on attachment 246921 [details] [review] Fix launching apps / search results in new workspaces by dragging Attachment 246921 [details] pushed as 5dabaf2 - Fix launching apps / search results in new workspaces by dragging
Created attachment 248171 [details] [review] windowManager: Actually respect hasWorkspaces We've long had the hasWorkspaces property, but it doesn't seem like it was ever used. Implement it so that we don't have workspaces in initial-setup mode. Since it's difficult to make it change at runtime with a decent set of semantics, and we never expect that to happen, don't bother implementing it dynamically.
Review of attachment 248171 [details] [review]: I tested by simply changing the hasWorkspaces property of the user mode, so I noticed that workspaces are still available in the overview. Would be nice to consider the property there as well, though I don't really expect a lot of use cases for (hasWorkspaces == false && hasOverview == true), so OK to commit without ... ::: js/ui/windowManager.js @@ +483,2 @@ keepWorkspaceAlive: function(workspace, duration) { + if (!Main.sessionMode.hasWorkspaces) Checking for (!this._workspaceTracker) instead would avoid an exception in case a sessionMode did (wrongly) change the hasWorkspaces property
Attachment 248171 [details] pushed as ed178b7 - windowManager: Actually respect hasWorkspaces Pushed with suggested changes.