Saving State

Saving an application's state essentially consists of recording certain bits of information about all of its top-level windows and their contents:

• Window locations and sizes, and application-specific information about their contents/identity

• The positions of widgets such as GtkPaned and GtkScrolledWindow

• The states of widgets such as GtkExpander, and the rows within a GtkTreeView

• The selections of widgets that support selections, such as GtkTextView and GtkTreeView

• etc

Some of this can be automatically recorded by gtk, but the "window contents/identity" part will generally require application intervention. (Eg, knowing that a window or notebook tab corresponds to a particular file, or has a network connection associated with it.)

Kinds of Applications and Their State

Single-Document Interface

Examples: eog, evince

There's general agreement that document-based apps should remember all of their document-specific state (eg, window size and scroll position) and restore it when opening that document again, independently of session management.

So an SDI app's session state is simply a list of currently-open documents; the app should already be storing document-specific state about each of those documents somewhere else.

(It's not clear if applications should save a separate per-session copy of document state when saving session state, rather than falling back to the "global" document state. That is, if I log out and save the session while reading page 5 of foo.pdf, then log in again and read up to page 10, then log out (without re-saving the session) and log back in again, should the document open at page 5 or page 10? Answer: it depends on why I saved the session at page 5...)

Multiple-Document Interface

Examples: gedit, epiphany

For session-management purposes, these are not all that different from SDI apps. The only difference is that if a window has multiple tabs, then the session state needs to record the contents of those tabs, and the window size and position becomes part of the session state rather than the state of any individual document.

Controlled Single-Document Interface

Examples: gimp, glade

These also work mostly like the SDI case, except that each "document" will have multiple windows associated with it. (The main document window, plus the current states of the various palettes, properties windows, etc. In glade's case, there will even be multiple "document windows" in a single "document".)

Non-Document-Based

Examples: most games, yelp, evolution

Since there are no documents, there is no per-document state. For many of these apps, there are arguments to be made on either side about whether their state should be saved and resumed on every run, or only saved and resumed when logging out and saving the session:

• When you start aisleriot, should it start a new game, or should it continue the game you were playing when you last quit?
• When you start yelp, should it show the table of contents, or should it show the help document you were last reading?
• When you start evolution, should it show the first unread message in Inbox, or should it show the message that was selected when you quit?

Either way, there are a few bits of state that probably make sense to save and re-apply every run, like window size and position.

Other non-document-based apps behave like they did have documents for session-management purposes. Eg, gnome-terminal should behave like an SDI app (or MDI if you use tabs); when you start a "fresh" copy, it should open a single window with appropriate defaults. When you resume it from a saved session, it should open windows corresponding to whatever windows it had open before.

Other?

Are there applications that don't fit into any of these classes?