gnome-session proposal

["William Jon McCann" <mccann jhu edu>]

Hi,

Dan Winship and Lucas Rocha have done a nice job revamping the
gnome-session codebase.  It was a meritorious task.  You can read
about the design here:
http://live.gnome.org/SessionManagement/NewGnomeSession

The new code is much cleaner.  Parts of the new design are very good.
In particular, using autostart as the database of
registered/automatically started applications, allowing use of a gconf
key to turn programs on and off, and starting up the desktop in phases
all make a lot of sense.

However, the core mechanism still relies on and is built around XSMP.
In my opinion, that is a mistake.  XSMP is broken is a variety of
ways.  Havoc argued rather convincingly that the state saving parts of
XSMP are broken (as well as the underlying protocol):
http://mail.gnome.org/archives/desktop-devel-list/2006-September/msg00088.html

I agree with that.  Logout handling is broken too.  The XSMP protocol
not only allows applications to be notified on logout (aka shutdown)
but also allows any registered application to block logout altogether.
 Windows XP used a similar approach.  However, in Windows Vista they
rejected that model and proposed a much better one:
http://msdn.microsoft.com/en-us/library/ms700677(VS.85).aspx

Vista's use of ShutdownBlockReasonCreate etc is analogous to the
various Inhibit APIs that we already use in GnomePowerManager and
GnomeScreensaver.  When a logout/reboot/shutdown are requested, Vista
is able to show a dialog warning the user if any applications are
running that would be interrupted by the action.  It informs the user
but still allows her to remain in control and continue the requested
action.  I think this is the right approach.  XSMP does not allow for
this.

Blocking shutdown is not only the wrong solution but it is also an
incomplete one.  One of the primary use cases here is burning a CD.
In the near future, switching users will also cause a CD burn to fail.
 XSMP does nothing to help with this.  On the other hand, using an
inhibit type API could.  The burning application could provide
information that the inhibit request should inform user switching as
well as logging out.  Nautilus transferring files to a USB disk could
do something similar.  But perhaps, a word processor would only inform
(ie. inhibit) logout and not user switching.

In addition to all that, I think that blocking logout and requiring
the user to find and unblock all necessary applications is not a good
user experience.  The user should be in control.  If I am running for
a plane and I want to lose the CD I'm burning rather than melt my
laptop in my bag that is my right.  (The above Microsoft document
about Vista changes talks about this scenario too.)  If the list of
"blocked" applications is right in front of me, making this decision
is much easier.  Another subtle problem with this type of prompting at
logout is that it is a great time to present a trojan prompt - I'm in
a hurry and I'll click or do just about anything to log out.

We can still support applications that only know if they should
inhibit "just in time" by emitting a signal when a logout is
requested.  The applications can then take an inhibit in response to
that signal.

So, if state saving and logout handling is broken, what is left of
XSMP.  Primarily two things: lifecycle tracking, and restart handling.

I don't think these are sufficient reasons to continue to solely rely
on XSMP.  We can do these very well using D-Bus.

In XSMP, the client notifies the manager if and how it should be
restarted.  This may be ok, and we can simply have the manager expose
a D-Bus API for this.  However, it may make more sense to simply store
this in the .desktop autostart file.

Lifecycle tracking is basically just start and stop/exit
notifications.  We can support this by having the manager export a
RegisterClient method and then watching for bus name changes for the
caller.


I think we have an opportunity to improve the user experience, improve
the application developer experience, and have a better chance of
making something that can be wrapped with a cross platform API that
lives in GTK+.

On top of this we could layer things like a more sophisticated session
saving and detection of favorite/recently used apps.  Maybe something
like:
http://live.gnome.org/SessionManagement/AutoSession


So, that is the idea in a nutshell.  I have a working version of all
this in (please give it a try):
http://svn.gnome.org/viewvc/gnome-session/branches/dbus_based/

The D-Bus API:
http://svn.gnome.org/viewvc/gnome-session/branches/dbus_based/gnome-session/gsm-manager.xml?view=markup

And the inhibit dialog looks something like:
http://www.gnome.org/~mccann/gnome-session/Screenshot-gnome-session.png

There is also a bug that contains some outdated information:
http://bugzilla.gnome.org/show_bug.cgi?id=535829

What do you think?

Thanks,
Jon