Re: session management subtlety

[Matthias Ettrich <ettrich trolltech com>]

On Saturday 01 December 2001 20:45, Havoc Pennington wrote:
> 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.

We don't do anything with "fast" (other than propagating it), "shutdown" I 
want to support.

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

Yes. I believe we usually do InteractStyleError for Local, and 
InteractStyleAny on Global.

>
> 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.
>

I thought a bit more about that and I think I'll change ksmserver to do the 
right thing:

   - support for requesting local session saves without shutting done
   - after pure global save, always delete the new session data. KDE and Qt
      applications won't write new session data and thus the discard command
      is empty (and I would appreciate if the gnome apps would do the same).
      But for compatibility, we definitely should run the registered discard  
      commands (even if I don't like it ).

I'm going to fix both ksmserver and kapplication (and probably Qt as well) in 
the KDE 3.0 branch. It might take me a few weeks to get time for it, though.

Thanks, Havoc, for bringing this up. I guess I start with the 
per-saveYourself saving in KDE.

Matthias