saving window states

[Havoc Pennington <hp redhat com>]

Hi,

Metacity doesn't have the feature where it can save window states on
the basis of the window's class/name. User requests for this indicate
that people have been using this feature in other window managers to
save window states. However, the feature seems broken to me.
Class/name don't identify windows uniquely, so I don't see how to
avoid for example restoring a main window's state to a dialog.

The other alternative is to have applications save their window
state. Once toolkits have support for the WM spec, this could be
reasonably effective. An app could save its position, maximization
state, etc. However, apps have to be aware of all pieces of state to
be saved, and specifically request each one. So if a window manager
has details of state that apps won't know about that state will be
lost.

Some use cases:
 - most apps should open main windows at the same size/position each
   time
 - to make gkrellm remember to be on all workspaces
 - most apps should _not_ remember their workspace (should 
   come up on workspace where they were launched)
 - document windows ("New Document") should probably follow some kind 
   of placement algorithm, but perhaps each specific saved document 
   should remember its particular state
 - conceivably some users want all windows to use the placement
   algorithm

Of course in the session management case, it's well-defined how saving
window state works.

On Mac and Windows, it's up to each app to save its state. On Mac this
perhaps works well since the UI guide specifies exactly what state
should be saved and how to restore it. On Windows, the effect is that
every app seems to do something different. Some always open in the
same place, some save position, some cascade each new document window.


Anyway, I think it's time we decided on how to fix this hard problem,
so that when we get bugs filed against apps for not remembering state,
or against the WM for not having the save-state-by-class/name feature, 
we know whether the bug is in the WM or the app.


Question: how much of the state to be saved is specific to the type of
window? For example, would some windows remember their current
workspace and some would not? Is the "type of window" here something
reflected by _NET_WM_WINDOW_TYPE, or would it vary within different
kinds of _NET_WM_WINDOW_TYPE_NORMAL?


Here is a possible toolkit API:
 char*  window_get_serialized_state (ToplevelWindow *w);
 void   window_set_serialized_state (ToplevelWindow *w,
                                     const char     *state_string);

The idea is that apps would get the string, stuff it somewhere, then 
put it back when they reopen the window. This API assumes that 
apps don't need to have input on what state is in the string. If 
they do need input, you could pass in a bitmask to
window_get_serialized_state() asking for only specific state aspects.

This API could be implemented in two ways:
 a) the toolkit reads the maximization and other aspects of state 
   using the WM spec hints, and sets them back; the string from 
   window_get_serialized_state() is constructed by the toolkit

 b) the toolkit gets the serialized state string from the window 
   manager via a spec extension, and falls back to a) for WMs that 
   don't support it, or for platforms that don't support it.

The current punt situation just leaves apps to figure out which bits
of state to save and where.

If we added some kind of hint to the WM spec we could let toolkits
decide between a) and b) I suppose, though I'm not sure we should put
b) in the spec if no toolkits are going to use it.

A disadvantage of b) is that application window states are
saved in a window-manager-specific way, unless we define the format of
the state string, but if we define that format there's little
advantage to b) over a) since we've hardcoded which aspects of state
get stored.


Anyway, all questions, few answers, but I would like to fix this
problem. Anyone have some good answers?

Havoc

(Tangent: a convenience API where the toolkit writes out the saved state data
file on behalf of the app might be:

 void window_set_save_state_id (ToplevelWindow *w, 
                                const char     *window_id);
 
i.e. window_set_save_state_id (w, "my_main_window") and then the
window would automatically load/save its state under the key
"my_main_window". I'm guessing we need an API this easy to really get
apps to use the feature. Possibly the window_id here is the same as
the window "role" for session management? Or somehow related?)