GNOME Bugzilla – Bug 737178
'workspaces on primary display' setting is forgotten
Last modified: 2014-10-14 08:42:15 UTC
See the attached video. Ignore the graphical corruption for now, I'll file a second bug about that. I use a command line run of gnome-terminal to put a terminal on my second monitor. But when I switch workspaces, it switches that terminal as well. Open gnome-tweak-tools, verify 'workspaces on primary display only' is already selected, toggle the setting twice, and now everything is working as expected. FWIW this worked on F21. Might seem like a contrived usecase, but I do that every day to run my todo list and a running status report on the second monitor.
Sorry: $ rpm -q gnome-shell gnome-shell-3.13.92-1.fc21.x86_64
Sorry, attachment was too big, give me a minute and I'll post a URL
Screencast: https://crobinso.fedorapeople.org/bugs/gnome-737178-primary-workspaces.webm
*** Bug 737349 has been marked as a duplicate of this bug. ***
Created attachment 287059 [details] [review] window: Be more careful when setting initial workspace state A window may either be sticky because it has been requested as such, or because it is placed on a non-primary monitor (and the corresponding preference is set). While we do take the latter into account, we currently override the sticky state later during initialization; be a bit more careful there to get the initial state right.
Review of attachment 287059 [details] [review]: ::: src/core/window.c @@ +1063,3 @@ if (window->initial_workspace_set) { gboolean on_all_workspaces; This variable might be uninitialized now
Created attachment 287074 [details] [review] window: Be more careful when setting initial workspace state Fixed uninitialized variable.
Created attachment 287075 [details] [review] window: Always set workspace state while constructing set_workspace_state () returns early when the desired sticky state and workspace match the current property values, assuming that the corresponding MRU lists are already correct in that case. However that might not be the case when we are setting the initial state, so don't take the shortcut in that case.
Review of attachment 287074 [details] [review]: Looks fine now
Review of attachment 287075 [details] [review]: Right, without this we'd never actually add the window to all workspaces initially in the meta_prefs_get_workspaces_only_on_primary() case
Attachment 287074 [details] pushed as 2eec11b - window: Be more careful when setting initial workspace state Attachment 287075 [details] pushed as 1e1ca47 - window: Always set workspace state while constructing
*** Bug 738075 has been marked as a duplicate of this bug. ***
*** Bug 736464 has been marked as a duplicate of this bug. ***