Session Management Proposal

[Ray Strode]

Hi Lubos,

>- Client Role - _DSME_RoleWindowManager : I don't like the part suggesting the 
>session manager should ensure there's only one WM running. First of all, 
>there's already a way how to make sure WMs don't clash, the proper way being 
>the manager selection described in ICCCM section 4.3, the less proper but 
>still working way being the fact that only one client can select for the 
>essential root window events. Moreover, suppose you run non-Xinerama dualhead 
>with one WM per screen - the session manager would actually break things here 
>if it tried (incorrectly) to ensure there's only one WM running.
>  
>
Okay, I'll remove that part.  I suppose a similiar problem could happen 
with
desktop handlers, so I'll remove it there too.

>- Also, I have a special hack in ksmserver+kwin for session saving, making 
>kwin perform saving in phases 0 and 2. There's no phase 0 of course, but the 
>WM actually needs to perform saving both before and after other apps save - 
>before if you want to save active window, active virtual desktop or stacking 
>order (because the 'save?' dialogs may change that), and after ... well, 
>that's obvious. Could such ordering be guaranteed?
>  
>
The most tempting solution, I think (for me at least), is to add 
something that
would say that when the session manager receives a SaveYourselfRequest
with global = True, it should send SaveYourself messages to clients in the
order they were registered.  The window manager should be started before
any applications that need a window manager, so that should work.  The only
problem is sometimes users switch window managers in the middle of the
session.

The slightly less desirable solution (for me at least) is to say that if 
a client
has the window manager role set, then the sm should send it the
SaveYourself message before other clients.  I guess this is really the only
way to get around the problem of window managers getting switched in the
middle of a session, so unless you have a nicer solution I'll add something
along these lines to the spec.

>- If I understand the proposal, all things that should be started by the 
>session manager have to register with it and save in the session. And, in 
>order to do that, they need to be running I guess. And in order to run, they 
>need to be started by the session manager ... - so, how will they be run for 
>the first time?
>  
>
Yea, msm currently has a default session file that contains enough 
information
to get some default programs started, in the right order the first time, 
until the
session is saved.

>  if it will have some predefined defaults specific to its desktop,
>  what's the point of standardizing this?
Well once the user has the default session started up, they have a usable
enough environment that they can then launch their own favorite 
applications
and configure the session how they want.  Say the user decides he wants to
use kdesktop (or ROX or whatever) instead of nautilus to manage his 
desktop. 
It would be nice if the user could just start it up, and it would 
automatically
register with the session manager, telling the sm that it handles desktop
icons and should be given a priority that fits that role.  Then when the 
user
saves session, logs out and then logs back in, it should be started before
normal applications and given any other special treatment for being a
desktop handler.  That's just one hypothetical, of course.

>- Could you perhaps describe how it works in GNOME now? 
>
Mark may be better at answering this than me, but here is how I think it all
works:
gnome-session first looks around for the session file which contains the
programs to load and the order they need to be loaded.  I think It first 
tries
~/.gnome2/session and if there isn't one there, then reads in default
values from $DATADIR/gnome/default.session.  Then it looks in
~/.gnome2/session-manual for user added programs, which is the same
format as the regular session file. Once it has read in all the session
information, then it throws up a splash screen and starts to load the
programs from the session data it just read.  Looking at the source,
certain things potentially start independent of the session, though:
esd, gnome-keyring, gnome-settings-daemon,  and the various a11y
programs.

> BTW, the ordering in the proposal seems a bit strange to me as well. Why 
>should the WM be started even before setup apps? 
>
Hmm.   I guess setup apps don't need a window manager and so they
can be started before the window manager.  I'll swap their priorities in 
the
document.

>And wouldn't it be actually 
>better to use something like our start-after? You don't actually care when 
>exactly the app will be started, you just know it has to be possibly started 
>after something.
>  
>
I'm not opposed to making it all relative instead of by doing absolute 
priorities.

My goal is that programs should be able to tell the session manager
approximately when they should be loaded on login.  If we do it relative to
other clients in the session, then a program should be able to say 
"start me
after any window manager is loaded"  or possibly also "start me after 
kwin is
loaded" ie by role or by program name. 

--Ray