Re: ICCCM breakage, IconicState, and desktops

[Havoc Pennington <hp redhat com>]

"Sasha Vasko" <sasha aftercode net> writes: 
> Not really simple. Firstly that does not resolve the problem with ambiguous
> state of unmapped windows, since there is sugnificant number of applications
> out there that relay on ICCCM compliant IconicState, so even if you unmap
> window without setting _NET_WM_MINIMIZED, they will still consider self
> iconifyed and start animating its icon window, instead of normal
> one.

IconicState is defined in the ICCCM to be ambiguous. The ICCCM says
(section 4.1.4) that the "top-level window is iconic (whatever that
means for this window manager)" and that WM_ICON_NAME can be displayed
instead of icon_pixmap or icon_window. Moreover, the EWMH spec already
implicitly discourages the use of icon windows and even icon pixmaps;
that's why we have the RGB format icons. Under both GNOME and KDE,
icon windows and pixmaps get totally ignored, pretty much, especially
if an RGB format icon is available.

Essentially, icon windows and pixmaps are deprecated, because they
can't be scaled, and the window can only be displayed in one place at
a time. So they don't work very well.

So, I don't think animating the icon window is in any way an issue.  I
don't think the ICCCM guarantees a viewable icon window in
IconicState. If it does, we can always put the icon window offscreen
somewhere and ignore it, but GNOME/KDE do not at present do that,
regardless of the outcome of this discussion. So no apps are going to
rely on the icon window being viewable.

> From the other hand, what would be the meaning of the state when IconicState
> is set but _MINIMIZED is not ? Its not good to override existing properties
> with new ones.

MINIMIZED does not override IconicState. What I was arguing for
previously, and Olivier is bringing up, is that IconicState in the ICCCM
just means "any state in which the window is unmapped, as defined by 
the window manager."

If you read on in section 4.1.4 in the ICCCM, it says:

 "In fact, the window manager may implement states with semantics
 other than those described above. For example, a window manager might
 implement a concept of an 'inactive' state in which an infrequently
 used client's window would be represetnted 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."

So in fact the ICCCM _explicitly_ says that you can put a client in
IconicState but NOT display its icon window and NOT have the client
"iconified."

IconicState has NEVER been equivalent to minimized. The ICCCM simply
defines it as any state where the client window is unmapped. The
strong guarantees made in the ICCCM are about the relationship of
map/unmap/withdrawn to IconicState/NormalState/WithdrawnState, the
ICCCM makes ZERO guarantees about what IconicState _means_ or whether
the icon window or icon pixmap gets displayed. Even if it did, as I
said we've basically already punted iconification and
icon_window/icon_pixmap in favor of minimization and task lists or
window menus.

The purpose of a MINIMIZED state is to tell pagers a specific _reason_
why a given window is in IconicState, vs. other possible reasons the
window may be in IconicState. MINIMIZED is not replacing IconicState,
it is complementing it by specifying additional information/details
about the window's state. This information is NOT currently reliably
available, using the ICCCM and EWMH as written.

> The disadvantages of putting windows in ambiguous state by unmapping
> only frame, is rather minor thing when compared to adding whole new
> property that overrides existing one.  AS I said before specs does
> not make approach of unmapping frame illigal, but, simple state
> dangers of it. Maybe the wording has to be changed to avoid
> confusion.

Because the spec lacks the MINIMIZED state, it does require you to use
IconicState only to mean minimized, not for any other purpose. Which
means you must violate the ICCCM if you want to unmap a window for any
purpose other than minimization. And there is simply no reason we need
to introduce this ICCCM violation or restrict window managers in this
way.

If your window manager only uses unmapping to mean minimization, then
adding the MINIMIZED state means you have to change exactly TWO lines
of code, to set/unset _NET_WM_STATE_MINIMIZED when you set/unset
IconicState. That is really, really easy - I don't see why you are
opposed to it. I don't see why forcing ICCCM violations is a better
alternative. What is the harm to adding those two lines of code?

> Unmapping both client and frame without need has other
> disadvantages, for example, if both frame and client are unmapped
> and window manager crashes - when it restarts, it may confuse such a
> client with withdrawn, since all of it windows will be unmapped.

Are you sure? According to the Xlib manual:

 "If the window manager dies, all windows listed in the save-set will 
  be reparented back to their closest living ancestor if they were
  reparented in the first place and mapped if the window manager has
  unmapped them"

Also, the ICCCM requires unmapping the client window if you unmap the
frame.

Havoc