Re: Proposal: _NET_WM_STATE_MINIMIZED

[Havoc Pennington <hp redhat com>]

On Mon, 2004-06-21 at 13:18, Lubos Lunak wrote:
> 
>  Is it? HIDDEN means hidden in any way. MINIMIZED is when I click that little 
> button near the upper-right corner, which makes the window to be gone and 
> accessible only using the taskbar or things like Alt+Tab.

When would you use this? It's not right to use it for whether to display
something as minimized in the task bar; the task bar (I think) should
display something as minimized if it's HIDDEN, not if it got hidden via
this specific mechanism.

If we just s/_NET_WM_STATE_HIDDEN/_NET_WM_STATE_MINIMIZED/ in the spec
does that solve the problem? ;-)

>  Come on, everybody knows what a minimized window is. That button in the 
> upper-right corner, you know :). If the spec has SHADED, why not MINIMIZED?

HIDDEN already serves the purpose, doesn't it?

What's actually broken right now? The only bug we've identified is this
minor confusion about whether a shaded window is hidden. GNOME and KDE
both say yes now, but we can change it to no.

Right now all the desktops and WMs are doing things the same way, it's
interoperable, it's backward compatible. It's not how we would have
designed it from scratch, but it does work.

>  For example, what does currently IconicState mean? "The window is hidden, but 
> I don't know why, and I can't also guarantee that NormalState actually means 
> the window is visible, so, in fact, all I can tell you is that I can't tell 
> you anything." Or the transitions - if a window is shaded or on another 
> virtual desktop (and is in IconicState), what should a request to change to 
> NormalState do? Unminimize? It will be a no-op then. Or should it act like 
> our _NET_ACTIVE_WINDOW message?

I bet if we catalog how the various WMs handle these, they all do
basically the same thing. We could then write it down in the spec, for
clarity...

metacity basically uses a MapRequest to mean _NET_ACTIVE_WINDOW, uses
WM_STATE when first managing a window to see if it should start
minimized, and honors a WM_CHANGE_STATE requesting IconicState by
minimizing. Metacity also sets WM_STATE as required by ICCCM (to reflect
map state though, not to reflect minimized).

The summary is that we've defined requests involving IconicState to
refer to "primary form of HIDDEN supported by the WM, usually minimize"
and defined the actual value of WM_STATE to be "whether the window is
mapped"

The ICCCM addresses the idea of "IconicState but not minimized" pretty
explicitly, see 4.1.4:

"In fact, the window manager may implement states with semantics other
than those defined above. For example, a window manager might implement
a concept of an inactive state in which an infrequently used client's
window would be represented as a string in a menu. But this state is
invisible to the client, which would see itself merely as being in the
Iconic state."

Then later in the section is some stuff about the unmapped == Iconic
invariant.

We could introduce new ways to request minimize/unminimize, but do we
really think the old ways can ever be deprecated or replaced? If we're
going to keep back compat forever we may as well make the old ways the
main way to do it, it seems like.

Havoc