np237 (np237) wrote,
np237
np237

The session non-manager

For various reasons (which in the end boil down to lack of manpower), we are quite late in the process of packaging GNOME 2.24. (This is almost finished now, I’ll keep you informed.) Which is why I may sound coming a bit late on noticing this one, but I was really speechless.

The problem: session management has flaws

Currently, a session manager uses XSMP (the X Session Management Protocol) to talk to applications. What it means is that for applications supporting this protocol, it is able to do more than simply starting and killing them: it will also remember their state, and offer them a way to shut down gracefully. However, XSMP is really a shitty protocol – I won’t explain why here, you will find tons of better explanations on the intarweb.

The gnome-session developers, being quite aware of this issue, did what anyone interested enough would have done: they designed a new protocol, based on D-Bus, and implemented it. The new protocol is not considered stable yet, but it is simple, efficient and above all, reliable – that’s a giant leap forward. For this reason, I was very excited to see what gnome-session 2.24 would look like, since it brings major cleanups in the code.

The solution: remove session management!

When I first started it, it did not restore my saved session. I simply supposed that the format of the saved session had changed, and that writing a conversion tool would be in order. Wrong. Let’s bring the session preferences:

The UI of this dialog hasn’t changed since 2.22. However, I do not resist the urge to show you the code behind the “Remember Currently Running Applications” button:

static void
on_save_session_clicked (GtkWidget           *widget,
                         GsmPropertiesDialog *dialog)
{
        g_debug ("Session saving is not implemented yet!");
}
As for the check box on top of it, it sets a GConf value that is never read anywhere.

If you know the long term plans for GNOME, it makes sense: when gnome-shell replaces the panel and the window manager, it will also be responsible for starting the visible applications, while gnome-session will deal with what’s happening behind the scenes. But gnome-shell is still far from ready, and you need something in the meantime for the basic requirements of a session manager!

Backwards compawhat?

The surprises don’t stop here. I also noticed that logout was much faster – instantaneous instead of the usual 2-3 seconds. The reason why logging out is this long currently is not because it takes long to kill applications; it’s because the session manager kindly requests applications supporting XSMP to shut down before killing them. If a document isn’t saved, an application will be able to prevent the logout process. Guess what? Now gnome-session completely ignores XSMP applications. Since it doesn’t need them to register for saving the session, it also saves the time to ask them to close cleanly.

The result is that you will see a lot of such dialogs:

It’s very nice to replace a flawed protocol ; and really, the new protocol goes in the correct direction. But let’s be realistic, it’s impossible to immediately port hundreds of applications to a new protocol without having a transition time during which both protocols are supported. You also need to consider your protocol as stable before asking other developers to port their applications. And to get it accepted, you need to standardize it; freedesktop.org would have been the correct body. (Currently, the protocol lies in the org.gnome namespace, not org.freedesktop.)

Release management at its best

Wait… aren’t there some distributions out there which already released stable versions with GNOME 2.24? The answer is yes. At least Ubuntu Intrepid and Fedora Core 10 ship with a session manager that:

  • is unable to restore applications;
  • kills applications without letting you save your work.

It’s good to see such improvements on the session manager coming, and I’m really thankful to the gnome-session developers to work on it. What I wonder is:

  • How could it slip into a stable GNOME release?
  • How could two major distributions let it slip into a so-called stable release?
It definitely looks like we’re not the only ones who could improve our release management processes.

So what?

This is a very good example of a lack of “big picture” thinking. On one side, there is a brilliant design and its good implementation. On the other side, two major regressions from the user’s point of view – the kind of regressions that make people fly away.

If there’s one thing that I’ve learned from working in IT, it’s that you must often keep your brilliant designs as long-term goals. In the short term, you will run a bastardized version of your brilliant design that will make you cry; but it will work. When you need to talk to shitty applications or with shitty protocols, you need to write shitty code.

Subscribe
  • 30 comments
  • 30 comments

Comments for this post were locked by the author