Re: ICCCM breakage, IconicState, and desktops

[Havoc Pennington <hp redhat com>]

John Harper <jsh eazel com> writes:
> 
> I don't think this is true. The ICCCM also requires that window
> managers unmap the client window itself `if an an ancestor window being
> unmapped renders the client's window unviewable' (section 4.1.4). The
> window will receive the associated UnmapNotify event

Right, but that's exactly the part of the ICCCM I'm defending here,
that I'm reading the WM spec as breaking.

i.e. the WM spec says "The second option is to keep all managed
windows as children of the root window and unmap the frames of those
which are not on the current desktop. This puts the clients in an
undefined ICCCM state, since they are unviewable, but not iconic.
In practice, this seems to cause no problems and the ICCCM compliant
alternative to iconify all clients on non-current desktops (without
showing their icons) is clearly not acceptable."

The 4th or 5th time reading this, I notice "keep all managed windows
as children of the root window" - I assume this means vs. virtual
roots, and the managed windows are actually children of frames.

But, anyway, I read this as recommending that clients not be unmapped,
just their frame. If you actually unmap the client, then the only
difference from ICCCM is whether you set WM_STATE or not - which I
think probably isn't a huge deal, it only affects pagers and
maintenance of state across WM restarts that I can think of.

Hmm, I guess that "unviewable, but not iconic" is pretty vague since
the whole paragraph is about breaking the ICCCM definition of
IconicState - I'm understanding this to mean "unviewable, but not
unmapped," but maybe that isn't the intent of the paragraph.

Havoc