Re: session management subtlety

[Matthias Ettrich <ettrich trolltech com>]

Havoc,

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. 
There are other places where they talk about saving state to a database and 
all you need to do is mark the data with the session ID.

I'd like to do the change in Qt, but since it might require a new method I 
cannot do that before 3.1. Alternatively, Qt might code the SaveYourSelf code 
into the sessionId argument. I'll see what I can come up with for KDE.

While we are at it, maybe we can even agree on a common interpretation of 
Local vs. Global?

It's this comment of yours that striked me:

>
> The problem with this is that it does not allow us to notify apps of
> the logout - so they can pop up "do you want to save?" dialogs -
> without also having apps save their updated state. i.e. it does not
> allow logout without saving current application state, does it?
>

I had the same problem. The safe logout procedure is a common, natural thing, 
and standard under most other GUIs like MS-Windows. Nevertheless there 
doesn't seem to be a way to achieve it with XSMP.

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.

This is where my interpretation of local and global comes from. I was 
actually convinced it was the one and only right interepretation and pretty 
obvious, until I received your mail and tried to read the specs with a 
different mindset.

It's in fact not entirely clear.

The example they give in the specs about how a wordprocess would react on 
SaveYourself gives some hints at least. On type Global they would simply save 
all open files, only on type Local they create a temporary file to save state 
information like what files have been edited, the current content, the cursor 
position etc.

This is why I interpreted Local, Global and Both this way:

Global - commitData() : 
	ask user whether he/she wants to save open files. If user hits cancel, abort 
	shutdown (if shutdown). Usually with interaction. No saving of state.

Local - saveState()
	save all state information silently. Usually no interaction. Open edited
	files are silently saved in temporary local buffers. This is the coolest 
	mode (and what KDE 1 tried to do with WM_COMMAND), but it's
	so dangerous that no users actually trusts it - and right they are.

Both - commitData(), saveState()
	first ask the user to save all open files, then store all state information. 


In KDE, Both is used if you logout and want to restore your session next 
time. Global is used otherwise.

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.

Do you run the discard commands everytime you logout from Gnome if the users 
does not want to save the session?


Matthias