GNOME Bugzilla – Bug 695487
Gnome shell reset moves windows to a different workspace
Last modified: 2014-06-09 20:37:40 UTC
After about a day my GNOME shell gets sluggish. My workaround is to run: Alt-F2 r, to reset the shell. It is great that this exists, because it doesn't close all the apps. However, any windows on the last workspace get moved, usually to the before last workspace. I currently have six workspaces. Let me know if you don't get this same behaviour when you test. Cheers, James
After further testing, I put one window on workspace seven, and I had stuff on workspace six. I did a reset, and the one window went to #5, and everything on #6 went to #1... Weird :(
Yeah, I've noticed this too with 3.6. If I remember correctly, most windows went to the first workspace, but not all of them (at least not all the time).
Seems to be fixed 3.8.1
(In reply to comment #3) > Seems to be fixed 3.8.1 Can you confirm that it's fixed when you're using 5 or more workspaces ? (with stuff on each)
(In reply to comment #4) > (In reply to comment #3) > > Seems to be fixed 3.8.1 > > Can you confirm that it's fixed when you're using 5 or more workspaces ? (with > stuff on each) I just tested with 6 workspaces. Seems to work fine.
For me this was fully working with version 3.8.2 (even with only 2 workspaces). Now that I have updated to version 3.8.3, the old behavior (all windows go to the first workspace again).
This still happens on GNOME 3.12, although not consistently.
Possible dup: https://bugzilla.gnome.org/show_bug.cgi?id=709997
FYI : When, after a crash, Gnome Shell erroneously restores 30+ windows (formerly spread over 6+ workspaces) to one single workspace, this is a lifesaver : http://blog.thewebsitepeople.org/2013/07/gnome-session-save-and-restore/
(In reply to comment #8) > Possible dup: https://bugzilla.gnome.org/show_bug.cgi?id=709997 No, different issue. This bug was fixed with https://git.gnome.org/browse/mutter/commit?id=2717a02a8d5da27364, but broke shortly after with https://git.gnome.org/browse/gnome-shell/commit?id=6c2f3d1d178a65dc. I hope to get this fixed for 3.14, in the meanwhile you should be able to work around the issue by running gsettings set org.gnome.mutter dynamic-workspaces true
*** Bug 709997 has been marked as a duplicate of this bug. ***
Created attachment 278030 [details] [review] main: Move pref overrides back into C Commit 6c2f3d1d178a65d moved pref overrides into JS to implement session mode specific overrides in a clean and generic way. However that approach comes with a cost - doing the overrides only after having handled over control to JS means that the core will be initialized with the non-overridden settings before changing to the correct values. In the best case this is unnecessary work, but it can in fact have a worse effect: when initializing workspaces, we will restore the previous number of workspaces when using dynamic-workspaces and reset to the configured number otherwise. As the non-overridden default for dynamic-workspaces is FALSE, we can easily end up moving the user's windows to the "wrong" workspace. Now GSettings is expected to grow support for session specific defaults, which will render our entire override system obsolete (yay!). Given that, it seems acceptable to use a less generic (and uglier) approach in the meanwhile, in order to fix aforementioned problems. So move overrides back before core initialization and just hardcode the session-mode => override-schema relation.
Review of attachment 278030 [details] [review]: OK.
Attachment 278030 [details] pushed as ae2751a - main: Move pref overrides back into C