Re: saving window states

[Havoc Pennington <hp redhat com>]

Matthias Clasen <maclas gmx de> writes: 
> >  - for any production, shippable window manager you can't
> >    ignore all the state and position requests by default.
> 
> Why ?

Because too many apps that users want to use will break. I assure you
that no operating system vendor can ship with all Java apps badly
broken by default, for a start.

Metacity originally _did_ ignore all position requests, btw. I tried
very hard to do this there's still a "disable_workarounds" preference
to switch it on.

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

Think of the problem not as that clients want to do their own
management, but that the window manager can't currently implement the
placement policy being discussed here (remembering window states
automatically).  This means that clients currently _must_ do their own
management, to end up with the UI being discussed.

You don't want this placement policy, but many people want it. I don't
see what's wrong with allowing the window manager to implement it.

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

There's no current way to implement the first (automatically), and yes
the EWMH allows the second, but then you lose the advantages of the
first. That's why it's a tradeoff, because both ways have
disadvantages. ;-)

I think there's probably a way to add a spec feature that has the
advantages of both, that's the point. I don't really see the harm in
such a feature.

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

I'm not sure I understand why you're arguing class/name/type are not
sufficient. Even assuming we can ignore all PPosition requests if we
have saved state under the class/name/type, which we can't, the file
manager example can't be implemented using class/name/type. The file
manager example can't even be implemented using manual user
intervention.

Can you explain how I would implement saving the file manager window
state for each directory, using class/name/type? This is a real-world
example, Nautilus tries to do it and Mac does it. I'm not sure if
Windows does or not.

Havoc