Re: saving window states

[Alex Hioreanu <spam uchicago edu>]

< Havoc Pennington [May 14 2002]:
> The other alternative is to have applications save their window
> state. Once toolkits have support for the WM spec, this could be

I don't like this idea very much.

Suppose I always want my web browser to open up in the upper-right
corner, where I can throw my mouse at it to move it somewhere more
manageable (this is exactly what I do with my own (unreleased) window
manager).  Now if the web browser remembers its state, it moves itself
wherever I closed it last time.  Basically, I DON'T want my web browser
to save its state, and moving this decision out of the window manager
and into the application denies me the opportunity to make this policy
decision on a system-wide basis.

Another example : suppose I right-click on an application that has been
minimized to the taskbar and close it from there.  The next time I
start up the application, I don't want it starting up minimized :
suppose the taskbar is the only way I have convenient access to
minimized windows and I'm not running a taskbar when I start up the
application the second time.  Point is, I don't want the application
nor the window manager to remember minimization state.  Leaving this
decision in the window manager leaves the decision up to the user.  I
can now choose a window manager that does not remember application's
minimization state, or one where this option is configurable, whereas
if this is moved into the application, I have to figure out how to
disable this with each toolkit I might run across (assuming the
decision of whether or not to remember maximization state is even
settable toolkit-wide).  Same problem with hidden, fullscreen,
maximized and shaded states that the spec describes.

In addition, there may be other kinds of state that the window manager
may want to save but which the toolkit doesn't know about, so the
window manager will end up having state-saving code anyway.  Suppose
the window manager has a feature where multiple windows may be attached
to a single frame, like pwm.  This is certainly state information
specific to the window manager, and it's reasonable for the window
manager to save this state with the application.  We now end up with
state-saving code in both the toolkits and the window manager.

Also : saving the maximization state like this probably means that the
application starts up with _NET_WM_STATE_MAXIMIZED_{HORZ|VERT}.  The
problem this raises is that this atom would then be used for two
completely separate things : (1) the application giving the window
manager an initial hint as to how the window should be dealt with and
(2) the application telling the window manager the window's previous
state.  For example, you might have a window manager that allows
arbitrary applications to be run full-screen by clicking a button in
the title bar.  It makes sense that the window manager would then set
_NET_WM_STATE_FULLSCREEN on any application which the user decides to
make full-screen.  Now, suppose you have a DVD playback program that
runs nicely in full-screen mode, so it's reasonable for the program's
author to set _NET_WM_STATE_FULLSCREEN on application startup.  I would
like to honor the DVD program's hint, but ignore the hint for the
spreadsheet that I last ran in full-screen mode.  This proposed change
then combines these two logically different reasons for setting the
hint into one, and the user can no longer distinguish between the two.

> 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

We should not be discussing this question.  This should not be our
choice, but rather the user's choice.  I mentioned that I don't like
*any* of these things being saved with the window, and I am sure that
there are other users who would like these things saved.  Leaving the
decision up to the window manager allows me to make the decision once
(by choosing an appropriate window manager), but putting this decision
into toolkits forces me to look up the appropriate gtkrc setting to fix
this, then figuring out how to set this in QT, but then I still have to
deal with individual applications that obey the WM spec but use
homegrown toolkits, and I am sure that there will be toolkits/apps that
don't allow this to be configurable.  Basically, my objections can be
summarized in that this proposal takes away control from the user.

As for class + instance not uniquely describing the window - the window
manager could look at class + instance + _NET_WM_WINDOW_TYPE + (class +
instance + _NET_WM_WINDOW_TYPE of window's WM_TRANSIENT_FOR) + ....
Although class + instance may not uniquely describe the window, using
other information can help describe the window less ambiguously.