Session Management Proposal

[Ray Strode]

Oswald Buddenhagen wrote:

>  we interpret "fast" as "shutdown without confirmation", regardless of
>  the user's setting (it is bound to shift-alt-ctrl-del, while the
>  "normal" shutdown is on "regular" alt-ctrl-del).

Okay, so you interpret the fast argument to mean "fast shutdown"
instead of "fast save" (i.e. shutdown = False, fast = True is
meaningless).  That sounds fine to me. 

>  "slow" would be just the opposite, i.e. "shutdown with confirmation",
>  regardless of the user's setting. independently from any other
>  client, only a part of the client doing the request. that _could_ be
>  useful for clients that want to initiate a shutdown without prior
>  explicit user action. i have no idea, whether this could be actually
>  useful for anything.

I'm not sure I completely understand this part.  By "slow" do you
mean fast = False or are you talking about adding something new to
the spec?

If by "slow" you mean fast = False, then to summarize:

type = Global/Both, shutdown = True, fast = False means:
Ask the user if they want to save their open documents,
then terminate the session.

type = Global/Both, shutdown = True, fast = True means:
Automatically save the users open documents without asking first,
then terminate the session.

If that sounds okay, I'll add it to the document.

>  exactly. we recently removed the last action saving, supposedly for
>  usability reasons. one can preset the default action in the control
>  center.

Okay I'll add a Default mode to the document.

> > I'm not really sure either. One consideration is if we add
> > "_NET_ShutdownModeSuspend" or whatever, then when legacy
> > applications see shutdown set to "True" they may assume that the
> > session is about to end and so they may act inappropriately.
> >
>  yeah, it's evil. i don't think that request should be forwarded to
>  clients that did not register for such an event explicitly.

Okay for now I won't add anything about this.  We could add a
SupportsSuspend property or something, but that doesn't seem like
a very nice solution. 

>  franky, i don't think we need to care for those who do not use a dm.

I guess this is really just an implementation detail.  The only
important thing is that the session manager needs to be able to
tell clients whether or not it has the ability to shutdown/reboot.
If one session manager supports consolehelper and another one
doesn't, it doesn't really matter so long as the desktop environments
know when to provide the shutdown and reboot options in their
dialogs and menus.

>  yup ... the desktop manager defines the session's life time, while
>  the session manager defines the session's actual life. it's sort of
>  self-evident that the two have to cooperate at some point to ensure a
>  smooth user experience.

If that cooperation gets standardized, too, that's great.  When you get
your dm spec drafted, we can add the required bits to the sm spec. In
the mean time, like George said, there are actively being developed
and that that anyone uses right now, so it shouldn't be too bad to cater
to them.

--Ray