Re: Session Management Proposal

[Oswald Buddenhagen <ossi kde org>]

On Mon, Dec 29, 2003 at 01:36:20PM -1000, Ray Strode wrote:
> >a counterpart to "fast" ("slow" - hehe) shutdown could be useful - if
> >fast means no confirmation dialog, slow would mean always confirm, even
> >if it was configured away - that could be useful for shutdown requests
> >"out of the blue" (for whatever reason somebody might want to do that).
> >
> So you are saying that:
>   
>   1) We should honor the fast variable from SaveYourselfRequest
>      messages (which was one of the open questions in my first
>      message).
>
yup. we already do that in ksmserver. it was matthias ettrich's
interpretation of the xsmp spec, and he explicitly said that nothing in
that document is really clear, so it might be plainly wrong ... :}

>   2) We should add a new client property that overrides the
>      value of the "fast" argument ("_NET_NoFastSaves" or
>      whatever).
> 
> Then, if a client initiates a SaveYourselfRequest method with
> fast set to "True", the session manager should ensure that no
> other clients have "_NET_NoFastSaves" set to "True" before
> propagating the fast = True value to each of its clients.
> 
> Did I understand you right?  This is to prevent potentials
> for abuse, right?  As I see it, there are two bad things things
> that a bad client can do if we honor the fast argument. 
>
> ...
>
uhm, no, completely wrong track. :}
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). "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.

> >>If the initiating client did
> >>+      not set the "_NET_ShutdownMode" property, then the session
> >>+      manager should assume an implied shutdown mode of
> >>+      "_NET_ShutdownModeLogOut".
> >>
> >>   
> >>
> >... for compatibility.
> >but then we need a mode "Default".
> >
> The default mode would mean the session manager gets to choose based
> on a setting or what the user chose last or whatever?  That seems
> useful.
> 
exactly. we recently removed the last action saving, supposedly for
usability reasons. one can preset the default action in the control
center.

> >another thing i'm wondering about is "Suspend" mode. considerations:
> >- like reboot/halt it might need authorization - after all it makes the
> > box unresponsive to network activity (apart from WOL, etc.)
> >- but it doesn't need to end the session
> >- still, it could be useful to tell all interested applications that
> > they should enter some passive state. i'm not sure this should be done
> > over xsmp, though - maybe some generic d-bus based system would be
> > more useful
> > 
> 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.

> >the next point is communicating the system shutdown request to the
> >desktop manager, as that's the place it belongs to. currently kdm has a
> >one-way command fifo and gdm has some fancy command socket. i'd like to
> >replace that with something common, possibly based on d-bus - dunno.
> >
> I agree that it would be nice if we could get the desktop managers to
> actually handle doing the shutdown/reboots.  Typically they have
> permission to do it, and they also should be able to know if there are
> other active sessions that should prevent the shutdown from happening.
>
exactly my reasoning.

> Having said that, the session manager can't really assume that there
> is a desktop manager I don't think, because some people don't use
> them.
> 
franky, i don't think we need to care for those who do not use a dm. if
you are not afraid of typing startx, you are not afraid of typing halt,
either. as far as local displays are concerned, a display manager is
only a convenience app - built-in shutdown is just another possible
convenience feature of it. if the dm does not announce being able to
shut down (possibly by being absent at all), the session manager should
obviously do the same (or simply ignore that part of the shutdown
request, just like ksmserver's dcop interface currently does).

> > [foo bar]
> >
> Okay, these features sound reasonable, but we are moving from the realm
> of session manager to desktop manager.
> 
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.

greetings

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