Re: The future of session management in GNOME

[Dan Winship <danw novell com>]

Havoc Pennington wrote:
> I don't think you're crazy, but can I suggest a good approach might be:
>  - start from what the user benefits / scenarios are
>  - figure out in a top-down way what API we'd like _apps_ to have
>  - then figure out how to implement that or something like it

Well, I would agree completely if we were starting from zero, but given
that we aren't, there are a lot of advantages to sticking with XSMP even
if it isn't the solution we would have come up with on our own.

My original theory (like everyone else's) was that we should kill off
XSMP. But (a) when I floated that idea internally, some people were
opposed to losing the ability to set up a default session, and (b) the
more I looked at XSMP, the more I realized that our problems with it
were as much the implementation's fault as the specification's. You said:

> Another way to look at why XSMP is broken is that there are two things:
>  - setting up your default desktop
>  - having apps guess that their last state is the one you're likely to
>    want again next
> 
> These really are not the same, XSMP mixes them together in a way that
> breaks both of them.

But as you also said, XSMP is policy-free, and I've come to the
conclusion that it's not XSMP that mixes and breaks things, it's
*gnome-session*, and by changing the way gnome-session works, we can
unbreak it. Hence my suggestion:

> >	* The confusing "always restore my desktop to its state from
> >	  March 7, 2005[2]" functionality will go away but be
> >	  replaced by two easier-to-understand equivalents:
> >
> >		* The "Save current state" checkbox at logout will now
> >		  say something like "Restart the currently-running
> >		  applications the next time I log in". This would
> >		  save state for a *single* logout/login, rather than
> >		  saving your current state for all time until you
> >		  save a new state. And perhaps the button remembers
> >		  its state between sessions?

aka "having apps guess that their last state is the one you're likely to
want again next"

> >		* In the session management UI, you can tell it to
> >		  take a currently-running app, and add it to the
> >		  autostarted apps list, and it will save its state
> >		  (ie, Local SaveYourself) and cause it to be started
> >		  the same way later. This is for things like "I want
> >		  my 17 gnome-terminals to launch in the correct
> >		  locations."

aka "setting up your default desktop".(I should have also mentioned that
in the save-state-at-logout case, after you resume, future logins revert
back to the previously-saved state [with your 17 gnome-terminals], not a
clean slate.)

Although a single piece of code in the application implements both bits
of functionality, there is no mixing or breaking from the user's point
of view. The two parts can be used separately or together, and either
part could be locked down by the administrator, and the other part would
still work fine.

So now we've got:

    * XSMP is currently the only cross-desktop- and third-party-
      compatible way of handling logout notification/cancellation

    * There are two useful use cases for XSMP-style session saving, and
      it seems like we're not far from being able to make them *both*
      work for any properly-XSMP-enabled app.

    * Pretty much everyone seems to agree that more state saving in
      general is good. And once you've got per-document/per-window state
      saving implemented, it's not much harder to implement session
      saving on top of that (you just need to remember *which*
      documents/windows are open in addition to what their individual
      states are).

And suddenly rather than "Die, XSMP! Die!", it looks like, "well, why
*wouldn't* we want to keep XSMP session saving around?"


> There are lots of apps that connect to the session manager and maybe
> implement the "please shut down" command, but I think nobody really
> implements the XSMP state-saving stuff, at least not correctly or well.

People have already mentioned gnome-terminal, totem, and gedit, and
there are lots others (eog, epiphany, evince... and that's just the "E"s).

OTOH, it's true that no one implements it completely correctly. I
couldn't find a single GnomeClient-using app that actually checks if
it's being asked to do a Local or Global SaveYourself. (gedit and
gnumeric always do Both, everything else always does Local.) Some apps
do things like saving state per-client-id rather than per-SaveYourself,
which mostly works with gnome-session but might fail under other session
managers.

But none of this is because it's *hard* to do the right thing; it's just
that there's no good documentation of *what the right thing is*, and the
GnomeClient API doesn't go out of its way to help you, and so most
people just copy and paste from other apps that either guessed wrong, or
themselves just copied and pasted from someone else, etc. So the same
set of misconceptions and bugs keep getting propagated from app to app.
But this can all be fixed with a sane client API with actual documentation.

Eg, something like:

    gboolean (*save_state) (GtkClient *client, GKeyFile *state_file)

The app just writes stuff to the GKeyFile and then returns TRUE.
GtkClient deals with all the icky XSMP details, like picking a
per-SaveYourself filename to save the data to, updating RestartCommand
and DiscardCommand to point to it, etc.

> On the implementation front, there is some amount of intrinsic problem
> with libICE/libSM - they are total junk and make it difficult to write a
> robust session manager app.

But gnome-session and msm have both already dealt with this, right? Does
the libICE/libSM suckiness leak, or can it be completely contained
within the SM and GtkClient?

>> (and extend XSMP where it doesn't do what we want, as we already
>> have).
> 
> I'm pretty sure I remember that the only way to extend XSMP is to add
> properties.

When I said "extend XSMP", I was thinking of the autostart spec. I guess
I meant "complement XSMP with new technologies", not actually "extend XSMP".

> There was some previous thread about having the session manager export a
> couple of dbus methods like Putenv/Getenv, so env variables could change
> dynamically during a session, I don't remember in what context this came
> up.

You're probably remembering the conversation about allowing the session
manager to change dbus-daemon's environment
(http://mail.gnome.org/archives/desktop-devel-list/2006-March/msg00104.html),
which we also need to do.

>> The clients would work like ssh-agent (print
>>       out a few VARIABLE=value lines at startup and then fork or
>>       exit), and there would be a new autostart .desktop property
>>       indicating that the client behaves this way. The session
>>       manager would start them, read their stdout, run the
>>       appropriate putenv()s, and continue starting things up.
> 
> Wouldn't a config file (or gconf) be simpler if you just want to
> statically configure env variables?

Yes, but they're not always static (eg, GNOME_KEYRING_SOCKET).

Maybe if both gnome-session and dbus-daemon implemented that
environment-variable-setting API, then anything that needs to modify the
environment of later apps could just make sure it starts early, and use
that. Or maybe we should just make things not depend on environment
variables, because they suck. (That would work for the keyring manager,
but not for G_DEBUG=fatal-criticals.)

The goal behind this feature was "you should never need to modify
gnome-session in order to add some new bit of (non-session-management-
related) functionality to the GNOME desktop", which, applied
retroactively, implies "get the special cases for a11y, vino,
gnome-settings-daemon, gnome-keyring-manager, etc, out of
gnome-session". Vino is trivial to get rid of; it just needed autostart.
Most of the other special cases involve setting environment variables
though, so I was trying to come up with a good environment-variable-
setting solution, and figured that the system already used by ssh, gpg,
etc, made sense.

>>     * The session management UI will be more icon-y and less
>>           command-line-y than it is now.
> 
> I'd say ideally the session management UI is shot in the head. ;-) It's
> kind of ridiculous. Why not just open nautilus on the autostart folder,

Won't work. You want to see both system-specified and user-specified
autostart apps, so it has to merge two directories together. And it's
not just merging, because the way you "delete" a system autostart app
from the list is to override it with another .desktop file in your own
autostart dir. So even assuming we don't want a single piece of
functionality beyond the autostart spec, we can't do the UI as just a
nautilus window.

I agree that the current session management UI should be shot in the
head though.

> The terminal case is about the only example I can come up with where the
> complex XSMP stuff kind of makes sense (and I think I made some sort of
> valiant attempt to implement session save correctly in gnome-terminal,
> come to think of it, that's why gnome-terminal has so many crazy command
> line options).
> 
> Even so I wouldn't be at all surprised if you surveyed a few dozen
> random sysadmin's systems if they weren't just manually running a
> terminal command line with the right options to launch the terminals
> they want. I wonder how many really use session saving to create their
> default config.

But it's hard to know if the lesson there is "people don't want session
saving" or "session saving in GNOME is currently sufficiently broken
that people can't use it to do what they want to do".

Either way, obviously it's nicer to be able to just set things up the
way you want, and then say "hey GNOME, in the future, set my terminals
up like that", rather than manually constructing a command line with the
right options for each window.

And again, part of the point is that by adding just a little bit more
code on top of the existing state-saving that you agree the app should
be doing anyway, that the app gets both set-up-ability and
resume-after-logout-ability (and, potentially in other session managers,
recover-from-session-autosave-ability,
multiple-different-set-up-ability, etc.)


If there was a strong argument for getting rid of XSMP to begin with,
then I might not argue for adding XSMP-style session saving to its
replacement. But if we want to keep XSMP for compatibility or whatever
anyway, and if there's a salvageable feature (or two!) hiding in XSMP
session saving, it seems worth it to keep that functionality.

-- Dan