Re: saving window states

[Matthias Clasen <maclas gmx de>]

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

There will always be crappy apps, no matter what write in the EWMH.

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

Yes. 

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

Why ? If apps start to "haphazardly remember random bits of state", 
I will go looking for a WM which does exactly that. If you don't
like that, just run a WM which implements a different policy. 

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

I know that configurability has fallen in disgrace lately, I don't
think it is adequate to disparage it generally as "obscure WM options".
What is wrong with having a WM configuration dialog offering the
option to ignore certain initial state settings. 
 
> 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'm all for moving them. I think the best we could add to the EWMH is 
a reinforcement of the basic ICCCM principle that the WM is setting the
window management policy and clients should not try to do their own
window management, even if the EWMH appears to give them the power to do
so. 
 
> > > 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.

I have not said that we should be globally ignoring PPosition and
application size requests. But even if I had said so: If this breaks 
existing apps, then they were already broken. The WM is the one who
is in charge of the window management policy. And "clients must
cooperate with the window manager by accepting the resources they are
allocated even if they are not those requested." (ICCCM)

> 
> 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 still don't see why any new feature is needed here. If apps know about
_NET_WM_WINDOW_STATE, they can save all or part of it and reuse it for
their next invokation. Older apps won't do that and keep working as
before.

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

But its not as if the EWMH would currently forbid either of these. Both
the wm and the client can do this. The only thing I can see that might
make sense to add to the spec is advice on how to associate saved state
with windows in case the WM opts to do this (i.e. identify a window by
class, name, type, etc).

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

I guess a section on window grouping by various means would be a good
idea. This has come up before.