*** Bug 686150 has been marked as a duplicate of this bug. ***

Looking  at mutter's debug output, the workspace seems to be reset when the Shell is shuting down as the initial desktop is indeed 0:

PLACEMENT: Read initial workspace prop 0 for 0x2800003 (Mines)

(In reply to comment #2)
> Looking  at mutter's debug output, the workspace seems to be reset when the
> Shell is shuting down as the initial desktop is indeed 0:
> 
> PLACEMENT: Read initial workspace prop 0 for 0x2800003 (Mines)

Hum actuallly no. The workspace is correct first but then the "initial" workspace is check once again for some reason and then is the first one.

PLACEMENT: Read initial workspace prop 4 for 0x3800003 (Mines)
PLACEMENT: Window 0x3800003 (Mines) is initially on space 4
PLACEMENT: Putting window 0x3800003 (Mines) on active workspace


(...)

PLACEMENT: Read initial workspace prop 0 for 0x3800003 (Mines)

I finally understood what's happening here:

- When starting mutter check the _NET_WM_DESKTOP prop of each window and find the right workspace (reload_net_wm_desktop).
- I then try to move the window to this workspace but fails because the workspace doesn't exist (only the 2 first workspace exists by default); this is in meta_window_new_with_attrs : meta_screen_get_workspace_by_index() returns NULL
- As window->workspace is NULL mutter moves the window to the active worskpace which is the first one.

I'm not sure what's the best way to fix this but here are some naive ideas:

a) Patch mutter to create the missing workspace rather than fallbacking to the current one.
b) In the Shell, save the number of used workspace and restore these workspace before loading windows in mutter. Once the windows have been loaded, drop all the empty workspaces.

That's strange. We should be reading _NET_NUMBER_OF_DESKTOPS and loading that many windows. Does that not get set?

I can't reproduce this - testing with various windows of gnome applications and 3-5 workspaces, I end up with the correct number of workspaces after a restart. So does this only happen with certain windows? Or maybe you are using packages with downstream patches?

I'm on Fedora 17 right now, I could check how many patches are around but I would be surprised to see many...

It could happen with a combination of random settings that modify workspace behavior, or extensions.

I'm using Shell and mutter master so no patch involved.

Ok, I think I finally understand what's going on here.

When starting, mutter reads the "org.gnome.desktop.wm.preferences
num-workspaces" gsettings key and creates that much workspaces.
You can check the value of this key using:
  gsettings get org.gnome.desktop.wm.preferences num-workspaces

So, if this number is smaller than the number of workspaces you actually had
before restarting the Shell, all the windows which are now without a workspace
end up on the first one.

An easy workaround is to change the value of this key to a number large enough
to cover your use cases:
  gsettings set org.gnome.desktop.wm.preferences num-workspaces 8

But ideally the Shell/Mutter should update this key when desktop are added/removed so
it stays sync. Or maybe this key should just not be used if "org.gnome.mutter
dynamic-workspaces" is true (which it is as Shell overrides it)?

(In reply to comment #10)
> Ok, I think I finally understand what's going on here.
> 
> When starting, mutter reads the "org.gnome.desktop.wm.preferences
> num-workspaces" gsettings key and creates that much workspaces.
> You can check the value of this key using:
>   gsettings get org.gnome.desktop.wm.preferences num-workspaces
> 
> So, if this number is smaller than the number of workspaces you actually had
> before restarting the Shell, all the windows which are now without a workspace
> end up on the first one.

Ah, that makes sense - thanks for tracking this down.


> But ideally the Shell/Mutter should update this key when desktop are
> added/removed so it stays sync. 

No, that is not an option - we used to do this, but it causes problems at session start: after restoring the last number of workspaces, empty workspaces (at this point - all but the first) are removed, which means the key has to be written to - which means dconf has to be started slowing down the overall login time.


> Or maybe this key should just not be used if "org.gnome.mutter
> dynamic-workspaces" is true (which it is as Shell overrides it)?

That's what we do for writes, we probably need to do this for reads as well then - maybe the easiest workaround is to use the upper bound (36) instead of the actual value of num-workspaces if dynamic-workspaces is true.

Why not simply read the existing _NET_NUMBER_OF_DESKTOPS key?

Created attachment 226674 [details] [review]
screen: Ignore num-workspaces when using dynamic workspaces

On startup, workspaces are initialized according to the num-workspaces
preference. However when using dynamic workspaces, the actual number
of workspaces in use might be greater than the preference (when
replacing the window manager), forcing windows on those workspaces
to the first workspace.
To fix, ignore the preference completely when using dynamic workspaces
and try to restore the previous number of workspaces (as read from
_NET_NUMBER_OF_DESKTOPS).


(In reply to comment #12)
> Why not simply read the existing _NET_NUMBER_OF_DESKTOPS key?

Sure, saves us a bit of adding/removing workspaces on alt-f2 r ...

Review of attachment 226674 [details] [review]:

Yeah, this makes sense to me.

Attachment 226674 [details] pushed as 2717a02 - screen: Ignore num-workspaces when using dynamic workspaces