Re: Proposal: _NET_WM_STATE_MINIMIZED

[Havoc Pennington <hp redhat com>]

On Fri, 2004-06-25 at 14:13, Elijah P Newren wrote:
> 
> Unless I'm missing something or just not understanding, this solution
> makes it impossible to have a window which is both minimized
> and shaded--or else makes it impossible for tasklists and pagers to tell
> if the window has both states set.

Shaded window = SHADED
Shaded/minimized window = HIDDEN, SHADED
Minimized window = HIDDEN
Unminimized, unshaded window = (blank)

2 boolean states = 2x2 = 4 combinations, each combination looks
different, right?

> I don't see any problems with this, and it seems to avoid the issues you
> bring up.

Only if the toolkits insulate apps to be sure they don't try to use the
MINIMIZED_TO_TASKBAR state.

> Then we can define HIDDEN = SHADED || MINIMIZED_TO_TASKBAR || SHELVED ||
> MINIMIZED_BY_WHATEVER_DERANGED_METHOD_YOU_CAN_IMAGINE.   :-)  Then hidden
> can just mean "don't show in pager" (as it is currently defined), instead
> of trying to rely on hidden to mean "it's minimized" and trying to deduce
> what in the world that really means.

For apps though they generally *should* want to know it's hidden, not
that it's minimized to taskbar.

In other words the proposal here is to split out the taskbar<->WM
communication

> > Any way we go, I think we're definitely at the point where we need a few
> > paragraphs of implementation note spelling out what task bars, WMs, and
> > toolkits should do, and giving a bunch of examples of what kinds of
> > HIDDEN are covered by the MINIMIZED state. Should also state invariants
> > such as "if MINIMIZED or SHADED then HIDDEN" etc. and state that
> > IconicState/NormalState corresponds to map state.

Reiterate this. The spec needs to specify things in a lot of detail
here, and specifically address taskbar vs. WM vs. applications/toolkits.

> > There's a very good chance that if we introduce MINIMIZED that this
> > happens:
> >  - apps start to use it
> >  - any WM that uses a different primary form of hiding just starts
> >    to interpret MINIMIZED as that form of hiding
> >  - MINIMIZED then means the same as HIDDEN
> >  - the spec is then really silly and confusing for no reason
> 
> Yes, I can see that this would happen.  But doesn't introducing
> MINIMZED_TO_TASKBAR (or otherwise very narrowly defined states) solve
> this and prevent this problem?

Only if we're very clear on the semantics in the spec, and spell out
what toolkits should do.

If we added MINIMIZED_TO_ICON at the same time perhaps, that might help
force clarity and keep people from using only the TASKBAR one.
We would also state in the description of MINIMIZED_TO_* etc. that they
are only used by taskbar<->WM not by app<->WM

> > I guess we're at the point where someone needs to draft the
> > implementation note for the spec, specifically noting what WM, task bar,
> > *and* applications should do. It should also define what the old
> > WM_STATE style hints mean, on startup, and when apps try to change them,
> > and when the WM sets them.

Need to do this ;-)

I do like your argument in bugzilla that this helps us fix the
what-gets-focused-on-(un)minimize issue, though we can probably solve
that in other ways as well (e.g. never focusing panel in the first
place)

Havoc