Re: ICCCM breakage, IconicState, and desktops

["Matthias Clasen" <matthiasc poet de>]

> What is exact definition of this new "minimized" state ? If all you want
is
> to hide window from the Pager then you really want HIDDEN state. For that
we
> already have _NET_WM_STATE_SKIP_PAGER/TASKBAR.

On the opposite, it should *not* be hidden from the pager, although it is
unmapped.

> Really try and define what exactly "minimized" state is, and you'll see
that
> it either indistiguishable from ICCCM defined IconicState, or requires
>  additional information to be meaningfull.

There are three states to consider here:

traditional NormalState: main window mapped, WM_NAME displayed

traditional IconicState: main window unmapped, WM_ICON_NAME (and possibly
icon pixmap/window) displayed

main window on a non-current desktop: we have to decide whether we want to
subsume this under NormalState
  or IconicState.

pro NormalState: Apps continue to animate WM_NAME, so that pager don't have
to represent the main window with
       WM_ICON_NAME (which some consider odd).  ((Btw I think the argument
about animating WM_ICON_NAME
        instead of WM_NAME is a bit bogus, isn't it ? Reasonable apps would
have to keep both uptodate anyway, since the
        titlebar will display outdated information after user-initiated
deiconification otherwise.))

pro IconicState: The ICCCM can be interpreted as incuraging the use of
IconicState for any state in which the main window
       is unmapped (e.g the hypothetical "inactive" substate of
IconicState).

  This decision in turn will force us to unmap the main window or to keep it
mapped, since the ICCCM has
  decided that UnmapNotify on the main window is the signal for clients to
track state changes.
  Unfortunately, the ICCCM also demands that wm frames and main windows map
state are kept in sync, so that deciding to
  subsume the third state under NormalState seems to force us to either
break the ICCCM by unmapping only the frame
  or to rule out non-virtual-roots-implementations of multiple desktops.

> > Application developers should not worry about wm state transitions at
all.
> > This is the job of the wm.
>
> Both IconicState<->NormalState transition and _NET_WM_STATE transitions
could
> be requested by client using ClientMessage. For example e-mail client can
> attempt to deiconify self when new mail arrives. I can just imagine it
> requesting deiconification when in fact it was simply moved off-desktop,
and
> it should have instead requested wm to move it onto active desktop.
>
> LIkewise client may request to be iconified after some period of
inactivity.

But I hope you agree that at least 90 percent of the cases where an
application developer
wants to fool with window states are just a mistake and an attempt to
overrule the wm's
window management policies.

Matthias