Re: The future of session management in GNOME
- From: "Ray Strode" <halfline gmail com>
- To: "Dan Winship" <danw novell com>
- Cc: desktop-devel-list gnome org
- Subject: Re: The future of session management in GNOME
- Date: Fri, 8 Sep 2006 11:07:55 -0400
* 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
So for this one, we should just switch over to using gtksettings instead of
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
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, 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
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.
] [Thread Prev