Re: The future of session management in GNOME


        * 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 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[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

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]