Re: saving window states

[Gregory Merchan <merchan phys lsu edu>]

On Fri, May 17, 2002 at 12:30:50PM -0400, Havoc Pennington wrote:
> "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.)

Incidently, I've seen IE do the same thing on windows.


> > 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:

Before this list, it should be clarified what parts are doing what.
The window and session manager interaction only serves to preserve
state between instances of a session and then only for windows in the
Normal and Iconic states. If the file manager has withdrawn or destroyed
a window, the state of a window, which appears to the user to be the same
one, should not (and cannot?) be preserved through SM/WM interaction.

For a file manager to always open a directory view in the same place,
it has to remember that place and indicate it to the window manager.
(The same holds for other bits of state.) If the window manager tries
to track this, then over time new windows will be delayed more and more
as the window manager has to search through its records for a match.
In the unfeasible long run, the window manager unchecked will consume all
available space with records for windows which may never appear again.


>  - 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.)

concur


>  - 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

WMs can also allow only some aspects to be restored.


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

concur

>  - 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.

concur


> 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.

I believe apps should be responsible for their own state and overridden
as needed for session-window manager interaction. However, they need
to know what properties to be responsible for. For this I recommend
the window manager provide a list of property atoms which apps should
remember. _NET_PRESERVEABLE_STATE(type ATOM[]) as a selection target for
WM_Sn, a property on the WM_Sn owner, and (ugh) a property on root are
simple viable options. A specially encoded string, as suggested earlier,
would be too limited and hard to change when needed.
(A better atom name than that though, please.)

> > > 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.

concur

> 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 so.

> > 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.

And some things I much prefer never save state, such as terminals. fwiw.
(Which does not exclude using a launcher to open a terminal with state.)

> 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.

Mozilla was also broken in this regard, last I checked.


> 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.

There's a problem with preserving position and size when a window is
maximized. The app should preserve the unmaximized values along with
the flag.


> > 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.

I'd think the per-app override would be command line options, perhaps set
with a decent UI to .desktop editing. Windows, iirc, has a checkbox
in its launcher properties dialog for starting maximized. (Maybe it's
a radio group for Max, Min, Normal. *shrug*) If the window manager doesn't
allow such a thing, the .desktop editor should know and adjust accordingly.

> 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

I think just telling apps what they should save will suffice.



Cheers,
Greg Merchan