Session Management Proposal

[Ray Strode]

Hi Oswald,

> >> one thing i'm not sure about is the "interact-style". without
> >> reading the xsmp spec it sounds like this is what matthias
> >> interpreted "fast" as. but then one would wonder what "fast" is.
> >> bah, i have to read the damn spec some day. :)
> >
> > Yea I think the bottom line is there are a bunch of not well
> > defined arguments and we just need to pick which ones were going to
> > use, and pick which ones we're going to ignore. "interact-style"
> > is sort of interesting because it is defined to have three values
> > so it could almost be used instead of "_NET_ShutdownInteractMode".
> > We could define "None" <-> "Passive", "Errors" <-> "Default", "Any"
> > <-> "Active". The only ugliness there is the "Errors" <->
> > "Default" mapping. I don't mind if we keep it the way it is now or
> > change it. Whatever you think.
> >
>  oh, there are already predefined constants ... uhm ... this has
>  potential to break existing apps, then. better not ...
Okay.


> > Something that just popped into my head, (and you may have been
> > trying to tell me this earlier and I missed it), is that right now
> > clients who want to shutdown send a SaveYourselfRequest with
> > shutdown = True and then the session manager responds by popping up
> > a little box asking what type of shutdown the user wants. With the
> > current spec, there is no way for this to happen anymore.
> >

>  there is ... usually with InteractModeDefault, enforcable with
>  InteractModeActive. iow, this popup box is what InteractMode is all
>  about ...

I realized as I was writing that email that you might have been
saying InteractMode was for that all along.

When you said "shutdown with confirmation" I thought you meant
"ask users if they want to save their documents".  And when you
said "shutdown without confirmation" I thought you meant
"save user's documents automatically without asking", but now I
realize you meant "ask the user how they want to shut down",
and "just shut down how the client wants" (respectively).

>  no, see above. i'd prefer to "abuse" the fast flag as a three-state
>  variable, provided libSM does not cut it to one bit somewhere. i
>  think it's save to assume that apps will actually pass 1, not
>  anything else non-0 as TRUE, so -1 (for example) could be interpreted
>  as "slow".

Okay, I experimented a bit with this idea and it doesn't work.  All
values beside 0 and 1 cause BadValue errors. 

>  eeek ... i think i'd put everything into one ARRAY8, simply defining
>  a struct - this could contain ShutdownMode (hmm, i called this
>  ShutdownType in kde) as well, so everything "post-exit"-related is
>  covered in one property.
This could potentially have alignment/padding issues I think (think
different compilers padding structures differently, or alignment
rules changing for processors that support 32-bit/64-bit mode.)
We could certainly group things into a LISTofARRAY8.  Although, I
don't particularly like that idea, because it would mean having to
either always putting things in the list in the same order (which
could cause compatibility concerns later if the dsme changes), or
packing some subproperty identification bits at the beginning of
each array which means giving each subproperty a magic value or
passing strings and delimiters around (ick). 

Regarding ShutdownMode versus ShutdownType, we can change the
spec to use ShutdownType, also.  I think it sounds slightly
better.

>  btw, do we have to care for endianess at
>  all? i.e., can XSMP wire data be actually passed across hosts?

I think theoretically it can because the XSMP talks about
transporting over tcp/ip.  I don't see why (or reasonably how)
desktop session managers would ever do it though, so you're
right endianess probably won't be an issue.

>  no ... the requests to the dm are always scheduled for after the
>  session exits by itself

Yup, my bad.  Actually I think GDM also has a way to say
"Shutdown now" (versus "Shutdown when everyone is done"), but
session managers should use the safe shutdown option.

>  not putting this stuff into the sm has only two disadvantages: a)
>  more code in the client and b) the client would have to cancel the
>  system shutdown request to the dm again if the session shutdown
>  request to the sm failed.
So you basically have:

Client1->DM: Reboot please.
DM->Client1: Okay, as soon as you log out I will.
Client1->SM: Log me out so the DM will reboot!
SM->Client1: One sec.
SM->Client2: We're logging out, if you're ready.
Client2->SM: One sec.
Client2->User: Foo.txt is currently not saved? Save, Discard, Cancel?
User->Client2: Cancel
Client2->SM: Nope, user doesn't want to log out.
SM->Client1: Sorry cannot right now.
Client1->DM: Nevermind, cancel the reboot.
DM->Client1: Sure.

It certainly seems possible, but having the clients initiate the
request only to potentially cancel it later seems a bit clumsy to
me.  It seems nicer if the DM doesn't get asked until all clients
in the session are ready. The session manager is the only one that
knows this information.

Also, compatiblity is a concern.  Clients expect to be able to
ask the session manager for a shutdown dialog.  That functionality
still needs to exist.

Finally, MSM is going to support shut down of sessions that were
initiated from startx instead of from a display manager.  If
clients are told to just interact with the display manager
directly then its up to them to support sessions initiated from
startx or from display managers that don't support the spec
you are going to write.  I think it's better to centralize it
at the session manager.

Okay so below is how I'm thinking things should work for GNOME.
i'm going to be repeating some things we've already agreed on,
just for clarification because i've misinterpreted some of the
things you've said before I think.
 
If I've missed something and/or KDE needs something that I
didn't mention then just tell me:

1) GNOME Actions menu needs Shutdown, Reboot, and Logout as
separate menu items. 

Therefore clients need to be able to tell the session manager
to reboot, logout, or halt the system.  (Mark Finlay pointed
this out), and they need to do it without the session manager
displaying any dialogs.

1.1) An additional option (which the GNOME panel doesn't need)
is for a client to be able to say "End the session now. I
don't care whether you shutdown, reboot, or logout, just do it
and don't ask the user first."  KDE would use this for
the shift-ctrl-alt-del thing?

2) The GNOME panel can also have a shutdown button.  In this
case the session manager needs to be able to pop up the dialog
box with radio buttons (or whatever) asking the user what they
want to do.  A client should be able to specify which radio
button is initially selected when the box first pops up.  Also,
the client should be able to tell the session manager "I don't
care which radio button is initially selected, you figure it out". 
Strictly speaking, the panel will probably always do the "you
figure it out" option, but there may be situations in the future
where the extra flexibility would be nice.

I think that's all GNOME needs, but there are two other things
that KDE needs (right?).

3) On the KDE panel you want to have a shutdown button. 
Clicking the button will do either 1.1) or 2) above based on
the user's settings. 

4) The other thing we've talked about in the past is when to
automatically save documents versus when to ask the user before
saving.  In GNOME, we will probably never give users the option
to turn off the "Your changes will be lost, Do you want to save?"
dialog boxes, but you said that is something you want users to
be able to turn off in KDE?

Okay so that's everything shutdown related, I think.  Again, if
i've missed something just tell me what, and an example of
how a client would use it.

So now we need to map that to new properties, so starting fresh
here is what i get:

--
_DSME_ShutdownType specifies
    reboot (_DSME_ShutdownTypeReboot),
    logout (_DSME_ShutdownTypeLogout),
    halt (_DSME_ShutdownTypeHalt),
    session manager decides (_DSME_ShutdownTypeDefault).

In the case of 1) it specifies which operation to do. 
In the case of 2) it specifies which radio button to initially
select.
In the case of 3) _DSME_ShutdownType will be _DSME_ShutdownTypeDefault.
--
_DSME_ShutdownInteractMode specifes:
   no user interaction (_DSME_ShutdownInteractModePassive),
   user interaction (_DSME_ShutdownInteractModeActive),
   session manager decides (_DSME_ShutdownInteractModeDefault).

In the case of 1)
 _DSME_ShutdownInteractMode will be _DSME_ShutdownInteractModePassive
In the case of 2)
 _DSME_ShutdownInteractMode will be _DSME_ShutdownInteractModeActive
In the case of 3)
 _DSME_ShutdownInteractMode will be _DSME_ShutdownInteractModeDefault
--
For 4) my first instinct is to have something like this:

_DSME_ShutdownSaveType specifies:
    automatic save (_DSME_ShutdownSaveTypeAuto)
    ask the user (_DSME_ShutdownSaveTypeAsk)
    session manager decides (_DSME_ShutdownSaveTypeDefault)

(which I what I thought you wanted InteractMode to be originally)

In fact, though, to do 4) you wouldn't need ShutdownSaveTypeAuto
or ShutdownSaveTypeAsk ever.  This is strictly a setting between
session manager and the user.  The client initiating the shutdown
doesn't need to be involved at all. 

In other words, nothing needs to be added to the specification
to handle 4).  Do you agree?
--
Note then that we ignore the fast and interact-style arguments
of the SaveYourselfRequest.

Good?
--Ray