Re: Session Management Proposal

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

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]