Re: Session Restoring All Windows on First Workspace

[Jeremy Hankins <nowan nowan org>]

Clinton Ebadi <clinton unknownlamer org> writes:
> Jeremy Hankins <nowan nowan org> writes:

>> Anyway, I do all this and discover that sawfish isn't being run with
>> the --sm-client-id arg at all, so it's running without session
>> management.  So I still can't test it out myself.
>
> The first time you run sawfish it is called with any SM arguments
> because it has not been saved as part of a session yet. After you
> logout of GNOME (`gnome-session-save --logout' or similar) a session
> is saved and the next time the --sm-{prefix,client-id} arguments are
> passed based upon what sawfish returns when queried in
> `sm-save-yourself'.

Ok, I was able to get this behavior by going into the gnome menus and
hitting "save session".  I'm guessing that you have it set to save
session automatically on logout?  Without saving session sawfish was
never passed session info even after logging out and back in.  Saving
the session only had to be done once, though.  Once I did that the
"failed to register before timeout" message that Chris mentioned went
away, as well as a lengthy pause before gnome got going on login.  Of
course, once I did that sawfish no longer started up at all until I
switched the location of the user initialization.

This points to a bug of some kind running sawfish with gnome, as when no
session info is passed gnome evidently still waits for some kind of
connection back from sawfish.  This never comes, leading to the timeout
message and a several-second pause.  My guess is that the proper thing
do to would be to check for the SESSION_MANAGER env variable, and go
ahead and try to connect even if no session info was passed on the
command line.  But it's probably clear by now what I know about gnome,
so that's only a guess, and I also don't know how that could be done
without a session-id.

>> This seems to be the result of a commit Chris made back in August of 2009:
>>
>> commit 379750f67d7227499a93b35dfa8c138d4ca5606f
>> Author: chrisb <zanghar freenet de>
>> Date:   Sat Aug 29 18:24:40 2009 +0200
>>
>>     changed position of user-level initialization
>
> It seems like it *might* be reasonable to restore the session after
> loading the user rc, but then again perhaps not (I don't see the harm
> in it). I can hack up another patch that splits the user rc loading
> and command line processing into two files and loads the former before
> session restoration and the latter after.

Before the above commit it ran the user-level init before connecting to
the session manager as well; it was done inside the let statement but
before connecting.  The only difference that the commit made that I can
see is that it changed when the session-id and session-prefix variables
were set relative to the user init.

It makes sense to me to do the user init before loading the session in
case something in the user init changes behavior in a way that impacts
loading the session.  I don't know exactly what that would be, but that
doesn't mean there isn't something.  So my thought is that we simply
revert the above commit, so long as whatever the original reason for the
change was it no longer applies.

-- 
Jeremy Hankins <nowan nowan org>