After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 602182 - Does not remember the number of workspaces on restart
Does not remember the number of workspaces on restart
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 616150 631801 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-11-17 11:01 UTC by Milan Bouchet-Valat
Modified: 2011-06-28 19:43 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Milan Bouchet-Valat 2009-11-17 11:01:20 UTC
Every time I restart my session I end up with only one workspace, with all the restored apps on it. That really breaks the idea of workspaces since I have to restore my organization of them manually.

Is that supposed to work ATM? FWIW, mutter is exiting with code 1 when I close my session - could it be that there's a problem on stop?
Comment 1 William Jon McCann 2009-11-17 12:31:26 UTC
How are they restored?  By XSMP?  If so, I'm not sure that is something we should support for 3.0.
Comment 2 Milan Bouchet-Valat 2009-11-17 14:10:30 UTC
Are you talking about the applications? I guess they are restored using different techniques, including XSMP, but also simpler implementations (gnome-terminal). It's not what I'm complaining about here, anyways. I'd just like to get as many workspaces as I had when closing my session when I restart it. Is that intended to work currently? I remember that Colin pushed some code about restoring some time ago, but I can't find the reference now.
Comment 3 Dan Winship 2009-11-17 14:52:10 UTC
Colin wrote some app-restoring code in bug 594802 but that was never pushed.

Mutter presumably does not save the number of configured workspaces when it saves its state, since we haven't changed that code from metacity, and metacity doesn't let you change the number of active workspaces to something other than what's stored in gconf. And even if we did restore the number of workspaces correctly, gnome-shell deletes any workspaces that don't have windows on them at startup, so that would happen before the restored apps were started.

This could all be fixed, if we wanted to.
Comment 4 Milan Bouchet-Valat 2009-11-17 19:31:00 UTC
OK, so this is just a matter of setting the Mutter GConf key to 1 by default, and save the number of workspaces to it. Then the Shell could stop removing all workspaces on start. I guess it would be good to have anyways - what should and could happen to applications is another issue.
Comment 5 Colin Walters 2009-11-17 19:43:41 UTC
(In reply to comment #3)
> Colin wrote some app-restoring code in bug 594802 but that was never pushed.
> 
> Mutter presumably does not save the number of configured workspaces when it
> saves its state, since we haven't changed that code from metacity, and metacity
> doesn't let you change the number of active workspaces to something other than
> what's stored in gconf. And even if we did restore the number of workspaces
> correctly, gnome-shell deletes any workspaces that don't have windows on them
> at startup, so that would happen before the restored apps were started.

Why were we doing that again?  Because the default workspace count is 4, and if you were only using one then you'd get blanks?

The best fix would be to implement the single-workspace view from bug 593844, then we could probably safely delete the delete-empty-workspaces code, and people who are transitioning from single-workspace won't see four big blank squares and wonder what the heck is going on at first sight.  (Leaves open the question of the default number of workspaces of course, which I do think should be 1)
Comment 6 Dan Winship 2009-11-17 21:53:27 UTC
(In reply to comment #5)
> Why were we doing that again?  Because the default workspace count is 4, and if
> you were only using one then you'd get blanks?

Well, we explicitly want the default to be 1, but it's controlled by a key in metacity's schema, so the way things work right now, mutter can't have a different default from metacity.
Comment 7 Max 2009-12-01 08:28:15 UTC
Here is another use case:

Every morning I have to
- re-add my 3 other workspaces because I am used to 4
- move my autostarted apps to the correct workspaces

what would be nice in this case is:
- either remember the number of workspaces or provide a config option [ other than manually using gconf ]
- provide a way to tell my startup-apps which workspace they prefer (kde has had this for a while)
Comment 8 Marina Zhurakhinskaya 2010-10-09 01:54:20 UTC
*** Bug 616150 has been marked as a duplicate of this bug. ***
Comment 9 Marina Zhurakhinskaya 2010-10-10 04:56:48 UTC
*** Bug 631801 has been marked as a duplicate of this bug. ***
Comment 10 Alessandro Crismani 2010-11-24 10:09:44 UTC
Adding my two cents on this, I find that having to recreate the nine workspaces I'm used to use (devilspie here) every time I start the shell and then having to move all the autostarted apps is a major pain.

Would it be possible to set a configured number of workspaces at startup? I don't mind having an obscured config setting with a default of one workspace, so that new users are not confused, however I would really benefit from starting with more (and I think other people would, given the number of duplicated bugs :) ).

PS: I am not sure if I should bump an old bug, but this one is referenced by many other duplicates, hence I posted here. Feel free to spank me if I did it wrong
Comment 11 Baptiste Mille-Mathias 2011-06-28 19:43:37 UTC
I think this bug can be close as in the new implementation the user has no choice on number of workspaces to create.