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 _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
