Re: saving window states

[Havoc Pennington <hp redhat com>]

"Matthias Clasen" <Matthias Clasen poet de> writes: 
> I would be seriously annoyed if the wm would start maximizing all
> new mozilla windows just because I happened to close the last one
> while it was maximized.

It already remembers its size, and the development branch remembers
maximization state. (You sort of have to do maximization, if you do
size, because otherwise it comes back with maximized size, but gets
run through the placement algorithm and not actually maximized, which
kind of sucks.)

> The functionality you want can already be provided on both sides:
> the wm can add an "Remember to maximize similar windows" item to its
> frame menu; the app can add a preference "Start maximized". Just
> drop the idea that any of this should happen automatically, it
> doesn't make sense.

Here is the issue:

 - if we do nothing, apps are going to haphazardly remember random 
   bits of state, automatically, often with no preferences.
   (I'll probably lobby for a GTK function to do this on 
   behalf of apps, so they are at least consistent.)

 - if apps do that, window managers can choose to deny all 
   such state requests (ignore _NET_WM_STATE on startup, 
   and ignore USPosition/PPosition), including legitimate uses
   of these, or they can let apps remember the state

 - for any production, shippable window manager you can't
   ignore all the state and position requests by default.

 - thus, state will be recorded per-app, inconsistently, 
   with no global way to toggle it, from the perspective
   of most users who don't fool with obscure WM options.

That's what will happen if we do nothing. I'm pretty confident it's
what will happen since it's already happened, more or less.

So my question to this list is whether you want to specify something
other than that. If not, then we should say that apps are responsible
for recording their own state, and the WM can choose to heuristically
or categorically deny what applications request. If we do that, I can
move all bug reports related to this to the individual apps.

> > However, I can't just automatically save state for all windows,
> > because in the real world, this means that many applications
> > break. Mozilla has the same class on everything. Java sets the class
> > based on which widget is used for the toplevel, so a similar thing
> > happens. There are too many bugs introduced by enabling
> > auto-save-state for all windows based on class.
> 
> Another argument for dropping the "automatic" bit. I wonder why you
> expect broken apps to pick up your new state saving mechanisms, but
> not fix the more fundamental brokenness of not assigning the proper
> types to their dialogs.

There's a key difference. PPosition and application size requests have
historically been honored for all windows. By globally saying "we will
not honor them anymore" you break existing apps.

If we _add_ a feature for allowing apps to save state, that doesn't
break any existing applications; a window manager can support that for
apps that understand it, while keeping the older apps working.
 
> I think your use cases clearly indicate that different apps have
> vastly different expectations about what and how state is to be
> saved.

Well, as I said originally, there's a tradeoff here:

 - allow the WM to pick which state to save; gives users ability 
   to make global policy decisions, allows the WM to save 
   state details that apps may not be aware of
 
 - have the app choose which state to save using the existing 
   EWMH; this means that the app can pick-and-choose which state 
   to save based on per-application concerns.
 
The question is whether the apps do have different expectations about
what to save. I don't feel that they do; my sense is that they all
want:

 - position
 - size
 - maximization state
 - stickiness

Those are all I've seen requested, and they seem to apply to all apps
that want to save at all.

My feeling is that the variation among apps is in what they consider
"the same" window for purposes of saving state; Mozilla treats all its
windows the same, while for a file manager each directory is has a
different state.

However, if we assume all apps want to save these same few things,
having the app do the actual saving is probably fine. It just means we
can't add or subtract things from the list of "stuff to be saved" on a
global basis.

> Regarding the placement algorithm vs. same place question: I think
> the best would be to add an app preference: "Open new windows at the
> same position", which users could just turn off to let windows be
> placed by whatever algorithm their wm uses. I don't think we want to
> start standardizing placement algorithms, do we ?

I'd expect many people to prefer to see this preference on a global
level, rather than per-app, perhaps with a per-app override. That
means in the window manager. I don't see how we get into standardizing
placement algorithms, the question is just how a window manager can
override saved window state with some placement algorithm, while still
honoring basic ConfigureRequests.

Think of it this way: if I want to implement the placement algorithm
"put applications where they were before," I need this extra bit of
information about which windows are "the same window" to somehow be
conveyed to the window manager. The alternative (and de facto) way to
implement the restore-previous-state placement algorithm is for each
app to override the standard placement algorithm, which has some
downside.

So the question I'm asking is, do we leave the de facto way, or add
something that allows WMs to offer "put apps where they were before"
alongside first-fit etc. as an available placement algorithm.

Havoc