Re: The future of session management in GNOME

["Ray Strode" <halfline gmail com>]

Hi,

>         * XSMP does a number of useful session-managey things (logout
>           notification, logout cancellation, specifying apps that
>           should be restarted right away if they crash, specifying
>           commands to run at logout, etc) which we currently have no
>           other way of doing, so we'd be forced to reinvent half of
>           XSMP if we ditched it.
So at this point I'm sort of of the opinion that logout cancellation
isn't really useful.

Apps should just be saving their state all along the way.  This is
interesting for other cases, too, like if the power goes out.  In
general, I don't think people should ever lose work, and having this
"save everything that's still open when the user just wants to get out
the door" step isn't really the right way to go about it.

I know this is punting the hardest part of the problem to every app though.


>         * To reduce the number of special case hacks the session
>           manager contains for various bits of GNOME functionality,
>           we'll add a way for autostarted programs to make changes to
>           the session manager's environment; eg, setting GTK_MODULES
>           for a11y,
So for this one, we should just switch over to using gtksettings instead of
environment variables.

>            setting G_DEBUG for unstable-series testing,
>           setting GNOME_KEYRING_SOCKET for the keyring manager,
>           etc--currently these are all done as special cases in
>           gnome-session. 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.
Sounds reasonable enough...my only concern is that apps tend to spew
things to the console without really realizing it.

>           We could make the splash screen a separate program too.
>           (Would this actually be useful?) The session manager has
>           .desktop files for everything it's starting, so it could
>           just do startup notification when it launches them, and then
>           the splash screen program could watch that to see what
>           icons/localized app names to put up. (We'd also need to have
>           the session manager signal somehow when the splash screen
>           should go away.)
Do we even need a splash screen?  Soeren turned if off by default in fedora.

>         * The session management UI will be more icon-y and less
>           command-line-y than it is now. (The session manager will
>           hopefully have a .desktop file for each app, so it can use
>           those to get icons and localized names.) It will probably
>           communicate with the session manager via dbus, rather than
>           using kludgey hacks on top of XSMP.
That sounds good.  One conclusion I came to the other day about
gnome-session-properties:

It has three tabs.  The first one isn't really useful at all, the
second one should be merged into gnome-system-monitor, and the third
one is the only one that really seems interesting.  Maybe it should
just be gnome-startup-programs?

> Of course we'll want to throw away the gnome-session codebase
> completely. (If you disagree, please go read the code.) The best bet
> would probably be to rewrite it in C#. I'm kidding. I'M KIDDING! The
> "msm" module that Havoc started several years ago and Ray Strode
> continued hacking on a bit later is probably a good starting point for
> a new session manager.
If you start with that, make sure you rip out DSME bits.  That spec
never went anywhere.

> We also want a better client API than GnomeClient. GnomeClient is a
> very very thin layer around XSMP, mostly because when it was written
> there wasn't enough agreement about what certain parts of XSMP meant,
> so it was impossible to abstract/simplify the API. As mentioned
> before, this is somewhat fixed now[3], so we can make a nicer API
> based on our new understanding. At the very least we want separate
> "save_state" (Local SaveYourself) and "save_files" (Global
> SaveYourself) signals, rather than a generic "save_yourself" signal
> with 36 possible combinations of flags where almost every single app
> in jhbuild that uses GnomeClient implements only one behavior that it
> uses regardless of the flags passed (and often that behavior is not
> 100% correct for any of the 36 possibilities).
msm has a client library, too, that Havoc was working on at one point.
It's probably too lowlevel, too, though.

> So I'm volunteering to do all of this:
>
>         * Write up a more detailed proposal than the above
>
>         * Propose extensions to fdo autostart spec, and a spec
>           covering the XSMP extensions and clarifications. (Hopefully
>           the XSMP stuff could also go into the autostart spec.)
>
>         * Finish/rewrite msm, add a migration path from gnome-session,
>           propose for 2.18 (or maybe 2.20)
>
>         * Reimplement GnomeClient as GtkClient, propose for gtk
>           2.something.
awesome.

> Does this make sense or does someone want to put forth a stronger
> argument for killing XSMP?
I don't have a strong argument against it, but I don't see what it
really buys us. Apps either don't support it, or support it very
minimally.  I wouldn't say it's that well understood, either.  It's
pretty ambiguous in places.

Having said that, I would love to see some improvements on this front,
and I'm sure you'll come up with something reasonable.

--Ray