Session Management Proposal

[Oswald Buddenhagen]

On Thu, Jan 01, 2004 at 08:50:33PM -1000, Ray Strode wrote:
> > 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. 
> 
hmm, that's not strictly a bad thing, unless we have the requirement not
to change libSM - at least it makes sure, that no app currently uses
something different.

> > eeek ... i think i'd put everything into one ARRAY8, simply defining
> > a struct - this could contain ShutdownMode 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.)
>
ok, so let's simply define a stream which is stored in one ARRAY8.

> 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). 
> 
indeed. well, one could simply put a version at the beginning of the
data.

both solutions (n properties or n fields in one property) have their
downsides - i think the "stream" solution is cleaner.

> > 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.
> 
kdm does have this as well, but only on the global fifo, not the
display-specific fifos - those can use the suicide command, if they feel
like that. :)

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

> 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.
> 
well, yes - as i said: convenience. and even elegance.

> 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.
> 
that's a strong argument, in fact. not that i like the idea of running
"halt" from inside a session, but that's not my worry ...

> 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),
>
yup

> and they need to do it without the session manager displaying any
> dialogs.
>
yes, but i do this only for shift-alt-ctrl-(del|pgup|pgdn). all
graphical entries and alt-ctrl-del pop up the dialog if configured so
(the default). is simply a safety measure to make potentially
destructive actions not reachable too easily.

> 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?
> 
no, i don't think it makes sense to do a non-interactive undetermined
shutdown. i mean, it's possible from the api side, but the kde ui does
not provide such a function. the non-interactive actions are directly
mapped to del->logout, pgup->reboot, pgdn->halt.

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

> 4) The other thing we've talked about in the past
>
actually, i missed that part. :}

> 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?
> 
now that you brought it to my attention, i'm pretty confident that this
is what the interact-mode is about: Any=normal yes-no-cancel dialogs,
Errors=auto-save and on error popup dialog with option to abort,
None=auto-save and ignore errors. kde currently implements only Any (i
think), so a _truly_ unattended logout under any conditions is
impossible - for normal operation that makes sense. emergency shutdowns
(power failure) could use one of the other modes.

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

> _DSME_ShutdownInteractMode specifes:
>   no user interaction (_DSME_ShutdownInteractModePassive),
>   user interaction (_DSME_ShutdownInteractModeActive),
>   session manager decides (_DSME_ShutdownInteractModeDefault).
> 
yup. but i think that to avoid confusion with the interact-mode option,
this sould be renamed to ShutdownConfirmation (Always, Never, Default).
note, that this dialog can contain confirmation, type (and
conditions/timing) selection and the option to whether the current
session should be saved, so maybe you can come up with some more
generic name. ShutdownDialog sounds most correct, but about any naming
clashes with interact-mode somehow - after all, they're very similar,
just that one applies to the session manager, while the other to the
managed clients.
i'd still prefer to (ab)use the fast flag, as it seems to be exactly the
right thing - just that we have the choice to patch libSM or abandon the
Always mode. hmm, maybe FastOverride is the correct name for a separate
property than, except that it's just as undescriptive as the fast flag
itself.

> _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?
>
uhm, well, let's assume, that interact-mode about exactly that. then in
principle it's exactly the same situation, as with the fast flag: the
requesting app can request a less interactive shutdown
(Confirmation=Never or fast=true), but it cannot request a more
interactive one (Confirmation=Always or fast=<errm ...>). ergo, again we
have the options a) do nothing, b) patch libSM extending the original
enum, or c) define an overriding property (IteractModeOverride if the
the other is FastOverride, or AutoSave if the other is Confirmation -
that seems consistent).

greetings

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.