XfceSMClient design

[Brian J. Tarricone]

I was originally going to post this to the bug[1], but it's getting a
little too long and rambly for that, so it's probably better to discuss
this here.  Warning: yes, this is long and rambly.  I did my best to be
succinct, but... I failed.  If you don't read anything else, please at
least scroll to the bottom where I question what our goal should be for
a SM client and comment on that.

I started working on XfceSMClient by just GObject-ifying our current
session client, but now I'm wondering if that's what we really want.

My guess is that something very similar to EggSMClient is going to make
it into gtk at some point.  In a way this is somewhat problematic,
because, at least for now, EggSMClient does some GNOME-specific stuff.
Presumably that would be fixed up before going into gtk, but we'll need
to watch this to make sure.  Previously, other GNOME-specific stuff that
has been proposed for inclusion into gtk has been made generic before
that, of course.

However, EggSMClient does some things weirdly:

1.  It expects the app to tell it the location of its .desktop file, and
then it pulls out a couple GNOME-specific keys to determine a few things
(one of them being restart style).

2.  It will make use of the env var DESKTOP_AUTOSTART_ID as the SM
client id if present.  xfce4-session doesn't set this, and I'm not sure
it's worth supporting.

3.  EggSMClient doesn't support SmRestartImmediately outside of reading
a special GNOME-specific key from the app's .desktop file.  If we want
to use the future GtkSMClient, we'd have to make sure support for this
gets added upstream.

4.  EggSMClient "enforces" the use of a GKeyFile to save application
state, and stores and names the file how it wants, not how and where the
app might want to store it.  This is potentially a good thing, but I
need to think about this more.

So I wouldn't be surprised if gtk decided to "standardize" some of
GNOME's practices...

At any rate, EggSMClient isn't meant to (just) be an XSMP client.
Rather, it's a generic session-managing/state-saving client thingo (and
in fact is meant to work on win32 and macosx).  For example, the signals
are more generic.  If we were to follow XSMP, we'd have:

* save-yourself: certainly useful in a generic implementation, though
I'd probably rename it to 'save-state' (like eggsmclient does) for clarity.

* save-yourself-phase-2: I'd probably drop this.  Usually only one
client on the desktop will use this: the WM.  (Though it would be nice
to have a hook for this so the WM can still use the SM client.)

* interact: useful, but I wonder if it makes sense as a signal.  Since
the client is required to freeze interaction with the user after
receiving SaveYourself (until it receives SaveComplete or Die or
whatever), the UI can't interact with the user anyway, so I'd think it's
fine for the app to *synchronously* request interaction in the
save-yourself signal handler.  In that case, there'd be no need for a
signal, as the xfce_sm_client_request_interaction() function would block
until it gets a response from the SM regarding whether or not it can
start interacting.

* die: useful, would probably rename to quit-now to emphasize that the
client is supposed to get itself dead quickly.  (And "die" just sounds
kinda weird.)

* save-complete: useful, but really XSMP-specific.  eggsmclient appears
to leave this out; not sure what they do in place of it.  The client is
supposed to freeze UI interaction until SaveComplete is received, but
this requirement might be ignored.

* shutdown-canceled: I would probably do as eggsmclient does and rename
this quit-canceled to be more generic.

EggSMClient also has a quit-requested signal, which serves to hide all
the InteractStyle, SaveType, and Shutdown XSMP stuff (arguments to
SaveYourself) from the API (quit-requested is basically
save-yourself+interact).  The idea is, when the client receives a
SaveYourself, we can do one of several things:

1.  Ignore it and just immediately respond with SaveYourselfDone.

2.  Generate a save-state signal: in this case the app saves "local"
state such that it can be restarted as-is, but doesn't commit changes to
"global" state (such as documents on disk).  The app also can't interact
with the user here.

3.  Generate a quit-requested signal: in this case the app can interact
with the user and possibly (probably?) save "global" state (such as
documents on disk).  The app does *not* save "local" state -- restarting
the app with the current client id and RestartCommand won't restore the
app's state.  The app shouldn't actually quit here, but will just
prepare itself to quit.  The app can also decide it doesn't want to
quit, and tell the SM that (the SM can later make it quit anyway).

4.  Generate a quit-requested signal, followed by a save-state signal.
In that case you get #3 followed by #2.

There's a nice little table in eggsmclient-xsmp.c that lists what
happens for the various values for the SaveYourself params.

Personally I think this is a good way to go in general, but I'm not sure
what our goal here should be:

1.  Write a generic SM client that hides the details of XSMP and will
work no matter what SM implementation we end up with (XSMP, DBus,
hybrid, whatever).  In this case we might not want to migrate to
GtkSMClient whenever it gets added to gtk.

2.  Just directly refactor SessionClient into a GObject and understand
that it's very XSMP-specific.  The thought here is that XfceSMClient
would be temporary and we'd deprecate it after GtkSMClient comes around
and migrate to that.

#2 presupposes that GtkSMClient will be suitable for Xfce.  Frankly,
EggSMClient... isn't.  I don't doubt that GtkSMClient will be more
desktop-neutral than EggSMClient, but that still doesn't mean it'll be
suitable for us.

#1 is "safer" long-term in that we have our own path that should always
work for us.  If GtkSMClient comes around, we can migrate to it, or
decide not to.  The downside is of course that we have to maintain our
own session client, and this feels a bit like NIH syndrome.  There's
also the question of compatibility: I'll certainly make sure
xfce4-session works well with whatever SM client we use, but if in the
end there's XfceSMClient, GtkSMClient, and still some stragglers using
EggSMClient, it's a bit harder to ensure interoperability.  There's also
the flip-side of that: we'd probably want to ensure that XfceSMClient is
compatible with gnome-session and maybe KDE's SM as well.

What do people think?

	-brian

[1] http://bugzilla.xfce.org/show_bug.cgi?id=5672