Re: session management subtlety

[Havoc Pennington <hp redhat com>]

Matthias Ettrich <ettrich trolltech com> writes: 
> you are right. I missed the advise in the specs that clients are indeed 
> required to save state per SaveYourself, not only per session :-/
> 
> Anyway I get the feeling this advice was put in later when they found out 
> that the protocol isn't as flexible or practical as they wanted it
> to be. 

Unfortunately the XSMP protocol (at least when using libSM) is
completely unextensible, as well. Which leaves us with very few
pleasant options.
 
> In fact, now -- after I change KDE to save per session _and_ per
> save yourself -- there is a way. On a normal logout procedure, the
> clients will save their states and the next thing the session
> management server does is to execute all discard commands.
> 
> But I don't like this. It's unelegant overkill for the probably most common 
> way of shutting the desktop down.

I agree that it's ugly. It is what gnome-session does right now, and I
think the only way to log out without saving given the current XSMP
spec. But we could change that.
 
> If you make Global save the state of the applications as well,
> including 
> things like cursor position, open files, what do you do if the user does not> want to save an edited file to the global storage although he modified it? 
> The cursor position when you restore the application will most certainly be 
> totally bogus. In other words: you would have to save temporary files as 
> well, but if you do that, there is no more difference between Global
> and Both.

My personal opinion is something like this:

 - saving to temporary files is too fragile and confusing for users, 
   and too hard for app authors to implement. As you say, it would 
   be really cool if it ever worked, but it isn't ever going to work, 
   so users never trust it or use it.

 - as a result, I don't think Local is really good for much

 - I'm mostly interested in SM as a way to save just the list 
   of open applications (and which windows they have open), 
   so losing the cursor position isn't that big a deal. 
   If the document doesn't get saved, the app could just 
   save a cursor position of 0 or something, or could close that 
   document window and not restore it at all. (important to close  
   the window prior to phase 2 so the window manager gets things
   right, of course, if it won't be restored)

   Also, even if the user does save all open documents, with 
   Global you still have the issue that they may edit those documents
   again, but not save the session after doing so. So I think the
   cursor-position-that-doesn't-apply-anymore problem is kind of 
   unavoidable in Global mode. For example, what if I set up 
   my session the way I want, then log in 4 or 5 times re-using 
   the same saved session each time.


For GNOME I think we care about two cases. One, we've traditionally
had a "save session now" button, so you don't have to log out to
save. This is used for example if you change your window manager (a
non-issue in KDE of course). I think it's also kind of nice to be able
to set up your preferred default applications and save, without having
to log out. Two, we want to be able to tell the session manager to pop
up the logout dialog, and offer to save session on logout, and have
apps ask the user to save open documents.

This means apps really need only three kinds of message:

 a) save current state, but don't ask about saving unsaved 
    documents, we aren't logging out. don't worry about 
    saving temporary document files; just handle it gracefully 
    if files change (e.g. open an empty window if a document 
    has disappeared when we restore)
 b) we're logging out, so ask about saving documents, but 
    don't save session state as user didn't want that
 c) we're logging out, so ask about saving documents, but do 
    save session state since user requested it

So the question is how do we encode those in the flags actually passed
to SaveYourself. SaveYourself has fast = TRUE/FALSE, shutdown =
TRUE/FALSE, and style = Local/Global/Both. That allows 
12 different messages, right, and we only need 3. ;-)

I think your suggestion is:
 Local = a)
 Global = b)
 Both = c)

And shutdown/fast are just hints that are mostly ignored, I guess.

Then we also have to specify that if the style includes Global,
interaction must be allowed; Global save with interact = None would be
nonsense.

I'm happy to go with your suggestion here, though I don't think it's
really what the XSMP spec means, I agree the XSMP spec is kind of
broken.

Havoc