Re: Proposal: _NET_WM_STATE_MINIMIZED

[Elijah P Newren <newren math utah edu>]

On Mon, 21 Jun 2004, Havoc Pennington wrote:

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

If you accept the following axiom:

   Tasklists and other programs do not need to be able to distinguish
   between the states (a) minimized and (b) minimized & shaded

then there is no use for a MINIMIZED state as far as I can tell.  But I
don't accept that axiom.  I also think accepting it leads to undefined
behavior for windows that are both minimized & shaded, and leads to
divergent implementations and understandings of the WM_STATE
IconicState (as Sasha pointed out, he says SHADED implies
WM_STATE=NormalState, while Metacity does SHADED implies
WM_STATE=IconicState).  Granted, these are mostly concerning "corner" use
cases, but why can't we get this corner correct too?

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

Uh... I disagree.  If what you say is true, then it should be totally
valid for the tasklist to show "Unminimize" for a shaded window.  But
this goes against a comment that you wrote in libwnck code;
libwnck/libwnck/window.c:

      /* 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;

Note that this also implies that libwnck can't tell the difference
between minimized and shaded at all, let alone between one of those
states and the minimized & shaded state.  (This could partially be fixed
using Sasha's interpretation of WM_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.

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

There's extra stuff to do too.  STATE_HIDDEN means don't show in the pager
(which is true for both SHADED and MINIMIZED windows, or at least that
appears to be the current choice).  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.  There may be
other small things as well.  If we do
s/_NET_WM_STATE_HIDDEN/_NET_WM_STATE_MINIMIZED/ then we probably need to
specify in the spec what pagers should show and what they shouldn't
instead of just assuming that SHADED or MINIMIZED == don't show.

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

Differentiating between minimized, minimized & shaded, and perhaps even
shaded.

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

You're ignoring the edge/corner case of users who make use of
both minimized windows and shaded windows and specifically the
possibility of windows which are both minimized & shaded.  These things
are basically resulting in undefined behavior.  That's fine if users
either (a) only shade, or (b) only minimize.  Otherwise, WMs are
unlikely to be doing the same thing (and if they are, they are
unlikely to continue doing the same thing) because behavior is currently
undefined.


Hope this helps,
Elijah