Re: Proposal: _NET_WM_STATE_MINIMIZED

[Havoc Pennington <hp redhat com>]

Hi,

Seems there are two possible courses of action, Elijah nicely sums the
problem with a quote from my code:

      /* FIXME this is really broken; need to bring it up on
       * wm-spec-list. It results in showing an "Unminimize" menu
       * item on task list, for shaded windows.
       */
      window->priv->is_minimized = window->priv->is_hidden;

There are two ways to solve this:

 - say that shaded does not meet the definition of HIDDEN
   (which I think is OK to do; the window is still 
   "visible on the screen if its desktop/viewport were active and its  
    coordinates were within the screen bounds"), "visible window" here 
   refers to the user concept of visible window, not the client's X 
   window, in my opinion, and the shaded titlebar could be considered
   a window that's still on the screen

 - introduce a MINIMIZED equivalent to SHADED which is a specific type 
   of HIDDEN

One worry I have is that e.g. if isMinimized() in a toolkit returns the
STATE_MINIMIZED I think most programs will do the wrong thing; they
should really be checking isHidden(), and most toolkits won't even have
an isHidden().

The de facto effect of having STATE_MINIMIZED may be that people ignore
HIDDEN and "alternative kinds of hidden" end up sort of broken :-/

I guess the point is that HIDDEN keeps the policy-freeness; MINIMIZED
encodes a specific UI (task bar plus the Windows-like titlebar buttons)

So I believe you guys are right that the task bar and window manager
should communicate about a MINIMIZED state (since they are part of the
specific UI) but it's probably evil for apps to play with a MINIMIZED
state, since we would like apps to remain policy-free in this respect.

Maybe someone can think of a good solution to that? We could maybe
recommend that toolkits only track the map state
(IconicState/NormalState) and hiddenness, and avoid tracking the
MINIMIZED flag.

Perhaps we could name the state MINIMIZED_TO_TASKBAR?

So we would explicitly say this state does not apply to "iconification",
or "shelving"? What if you have a "window menu" instead of a taskbar?
If it applies to iconification and menus, is it MINIMIZED_TO_ICON (ICON
broadly meaning "some small item representing the window")? 

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.

> But the real reason I disagree is that I personally think that 
> "minimized
> to the taskbar" (which is exactly what I mean by minimized) is
> fundamentally different from SHADED, SHELVED or whatever other HIDDEN
> states there are.

Fundamentally different how and to who? I agree that the implementation
of the window manager (and other desktop components such as task bar)
have to care about this, but I don't think apps for example should care
because then you effectively can never change the desktop model.

> There's comments in the spec about
> ignoring manual changes of the STATE_HIDDEN property, whereas there'd
> be
> no reason to ignore them if it were to mean STATE_MINIMIZED.

I don't agree with that necessarily; if toolkits start toggling
STATE_MINIMIZED instead of doing XIconifyWindow(), then any WM
implementing an alternate kind of HIDDEN would probably break. What apps
would usually mean when calling a "Minimize()" method is "do the primary
form of hiding a window for this WM", and toggling STATE_MINIMIZED
instead means "do the specific minimization used by Windows-style WMs"
(note that even Mac lacks this, it has the WindowMaker-style icons,
right?)

In any case, the basic point is that right now we have an abstraction
for "primary form of hiding a window for this WM" and we mostly force
apps to use it.

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

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.

My basic argument is that the application recommendation should keep the
policy-free aspect, by forcing apps to use HIDDEN, not MINIMIZED, and
keeping a way to ask for "(un)hide via primary mechanism"

Are we sure a simple "SHADED does not imply HIDDEN" is such a bad
solution? It seems pretty simple.

Havoc