Re: Session Management Proposal

[Ray Strode <halfline hawaii rr com>]

Oswald Buddenhagen wrote:

> 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.
>  
Changing libSM means either trying to convince XFree86, and Sun, and
all the other vendors that ship X to apply our patch, or shipping our own
libSM replacement with the desktop environments.  Doing the first
thing is going to be very hard and if we're going to do the second thing
then we might as well add new API.  Personally, I think it may just be
simpler to work within the means provided already (Namely, properties
and defining our interpretation of message arguments).

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

So you're saying instead of copying the /struct/ bit-for-bit into
the ARRAY8 (which has padding/alignment issues), you would rather copy
each /field/ bit-for-bit (ignoring all padding).  Implementing that
is going to be really messy. Why do you want to send it over the wire
grouped together?  once you get the data there is nothing preventing
you from storing it more structured, but it seems a lot easier
implementation-wise to just send the data as individual properties.

>  both solutions (n properties or n fields in one property) have their
>  downsides - i think the "stream" solution is cleaner.
Conceptually it's cleaner to say "these properties are grouped", but
it complicates implementation quite a bit with no real added benefit.

I think if we knew we were going to be needing a lot more added to
the spec where structures would be more generally useful then it
would make sense to develop a more formal grouping type, but the XSMP
does basically what we need already.  It just needs a few more things
for desktop environments to work well.

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

Okay so shift-alt-ctrl-(del|pgup|pgdn) basically does 1) and
alt-ctrl-del does 2).  In that case we don't need to support
1.1 or 3 at all.

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

> > 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.
Right.  This was just a product of me misinterpretting what you were
saying I guess.  The reason I had another property for this instead
of using interact-style is beceause I thought you needed another
option "Default" that has the session manager pick yes-no-cancel or
auto-save.  Now that I see you don't need it, we can get rid of the
property and just use interact-style.

> > _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).
Sure.

>  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,
_DSME_ShutdownDialog with _DSME_ShutdownDialogShow,
_DSME_ShutdownDialogNone, and _DSME_ShutdownDialogDefault is fine
with me.

>  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.
Abandoning the Always mode is fine me with. 
fast = False means what _DSME_ShutdownDialogNone would have.
fast = True means what _DSME_ShutdownDialogDefault would have.

Is there ever a time when a client would want a shutdown dialog
against the user's settings? No, I can't really think of one, so two
states is fine.

>  FastOverride is the correct name for a separate property than, except
>  that it's just as undescriptive as the fast flag itself.
yea if we were going to use a property then i would prefer something more
descriptive, but if using 2-state fast is enough for you, then i'd prefer
just go that route.

> > _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 ...>).
Okay, so actually interact-style is sufficient for what we need.

interact-sytle = Any   (Session manager decides based on user
                       configuration)
interact-style = None/Errors  (Do not have "do you want to save?"
                              dialogs)

There is never a situation where the a client should be able to
request "Do you want to save?" dialogs if the user has it turned
off. (Again, though, GNOME probably won't make it a configuration
option to begin with).

okay so to summarize:

_DSME_ShutdownType stays, but everything else goes.

When the client sends SaveYourselfRequest, both fast and
interact-style are significant.  They each specify whether the
session manager should follow user settings or be completely
uninteractive.

fast = False means display a ShutdownDialog if the user has
            ShutdownDialog's configured to be shown.

fast = True means don't display a ShutdownDialog, the client has
           already secified specifically how they want to
           shutdown.

interact-style = Any means display
                    "Do you want to save document 'foo'?"
                    if the user has save confirm dialogs
                    configured to be shown on logout.
interact-style = Errors means display
                       "There was an error saving document
                       "'foo', do you want to cancel
                       shutdown?" if there is an error, but
                       otherwise don't display save-confirm
                       dialogs.
interact-style = None means don't display save-confirm dialogs.

Sound good?

--Ray