TedPage: Who cares when we quit?

At UDS we talked a lot about how a users leaves the system. We're of the general feeling that the mammoth dialog that's in Ubuntu today isn't the way of the future. But, what is it? Much of that discussion is now going on in the ExitStrategy wiki page.

One of the things we realized is that we'd really like to give more information to the user when they're leaving. Which programs have unsaved data? Who will complain when I leave? Can I just say no to all of them? We don't really have a way to find all of this out, and to enforce our choices. Assuming every application has session management: how should we do it? That lead me to the spec for XSMP. Being a graphical person I immediately jumped to "Client State Diagram" in the table of contents. Let me show you the "diagram":

So that encouraged me to actually create some diagrams using Graphviz with a little bit of cleanup using Inkscape. I think these are much more in the spirit of diagrams. (they could use more cleanup though)

XSMP Session Manager State Diagram	XSMP Client State Diagram
( Dot | SVG | PDF )	( Dot | SVG | PDF )

It looks like we can "query" whether the application is going to interact with the user by asking it to save everything, and if we get an Interact request we say "Just Kidding" with a ShutdownCancel. It seems likely that everyone who wants to interact with the user would be doing so for some sort of unsaved data, though we are not guaranteed that. Here's what I'm thinking in a sequence diagram, help from MSCGen and Inkscape.

XSMP Sequence for Checking Save

( MSCGen | SVG | PDF )

While I think this could work, the "A bunch of work" area of the diagram scares me. If an application doesn't want to interact there is potential to do a large sum of work before communicating back to the session manager which could effect our interactivity. Especially considering one goal was to decide whether the menu item was "Quit" or "Quit..."; which would have to be done every time the menu is opened.

In a nutshell, we need to cache this data somewhere so that we're not asking the applications every time. They should push it. One place is to add another property to the XSMP that states you have unsaved data. Another would be a window manager hint. Heck, we could invent our own DBus API (everyone's doing it) for the information.

Independent of implementation, having this data would be good for shutting down, but I think it has other significant impacts to the user experience also. Currently most applications change their title message to include a * when the file is modified, seems silly that we have to encode this into a string. If we had this information somewhere that the window manager could get at it, the WM itself could take care of this notification. Perhaps changing the title bar color, making it less wobbly, or simply putting a nice themeable star at the top.

The other advantage of having this value independent of the sequence diagram above is that we don't want applications to ask for interaction. No, really. It would be better if they were to save the file temporarily someplace else, and then restart in the same place they were before; including the undo/redo buffer reestablished. In this way logging out becomes a non-destructive operation. You don't loose your state, but you also don't have to commit to a particular version of a file.

At the end of the day I think we'll have to try the query that I've outlined here, but I'm unsure how many apps will correctly support it. But, we need a better long term solution for all apps and future user interactions.