Re: Proposal: _NET_WM_STATE_MINIMIZED

[Elijah P Newren <newren math utah edu>]

On Thu, 24 Jun 2004, Havoc Pennington wrote:

> 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

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.  In other words, this doesn't solve
Lubos' problem.  Note that although Metacity and Libwnck have ignored
this problem, they have the same problem too (there is no effort to
prevent a window from having both states, and libwnck can't (correctly)
handle a window having both)

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

To be discussed further below, but basically this is what my vote is for.

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

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

> So we would explicitly say this state does not apply to "iconification",
> or "shelving"?

Yes.  I think all of our problems are coming from assuming that MINIMIZED
can be a general state instead of a specific one, and not being able to
count for all generalities.  So I think we do want a very specific state.

> 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")?

While I can see those states having the same semantics as
MINIMIZED_TO_TASKBAR, I don't see why we have to assume that they will.
And I don't see why we have to forcibly not allow more than one to
coexist (not that I personally want to write one that has more than one
of these coexisting).  Why not just leave open the possibiliy for
adding _NET_WM_STATE_MINIMIZED_TO_MENU and _NET_WM_STATE_MINIMIZED_TO_ICON
in the future?  In particular, I'm thinking of the following.  (Again,
tell me if I'm way off track, as I'm still new to this):

All sane window managers will detect WM_STATE changes from NormalState to
IconicState, and cause its favorite form of hiding to occur.  It will
detect WM_STATE changes from IconicState to NormalState, and undo all
hiding states.  If the window manager (and tasklist, etc.) wants to
provide the user ways to manually set other hidden states, or to undo
only one of the hidden states instead of all of them, it can do so
through toggling the appropriate _NET_WM_STATE_* atom.

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.

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

You previously stated/implied that SHADED was a subset of
MINIMIZED_TO_TASKBAR.  I was just saying (in a not very clear way, I
guess) that I thought they were independent states.

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

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?

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

I think my above suggestion does this, but then again, I'm new.  Did I
miss anything?

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

Hmmm...  It appears to be a solution that assumes a window can't be
both shaded and minimized-to-taskbar, and will only work so long as that
is enforced or we don't mind undefined behavior when users start doing
such things with windows.  While I don't mind an implementation that
enforces them to not be used simultaneously on a window, I think using
this solution would result in others (who want to do such things)
breaking the spec.


Elijah