Re: ICCCM breakage, IconicState, and desktops

[Havoc Pennington <hp redhat com>]

raster rasterman com writes:
> On 12 Jun, Havoc Pennington scribbled:
> >  
> >  The problem with what the WM spec says is that clients can become
> >  unviewable with no notification - the ICCCM ensures that you always
> >  get UnmapNotify if you become unviewable. So say you wanted to stop
> >  using CPU when not viewable, which would make sense for some clients,
> >  you can't really implement that.
> 
> actually you can quite easily - use visibilitynotify events :) they
> will tell you if you are fully obscured, partially obscured or
> completely unobscrued - regardless of what the wm may or may not do. if
> the wm like the ides of hiding a client window by moving it to 10000,
> 10000 - so be it. the visibility notify stuff still works.
> 

My example was probably not very good - I don't mean whether the
window has any region showing onscreen, there are two interesting
things I can think of:

 - whether the window is explicitly "hidden" in a user-initiated way
   (whether shaded, minimized, or off-desktop) - you don't get any
   notification of this separate from just covering the window with
   another window
 - whether the window is viewable (i.e. ancestors all mapped)

I'm not sure I can come up with a good example of why you need to know
these things, but the ICCCM seems to go to some lengths to be sure you
can know them, and what the WM spec recommends instead seems like a
Bad Hack (tm) that could easily have been replaced by a clean,
consistent feature like _NET_WM_STATE_MINIMIZE.

i.e. basically the ICCCM has a concept of "window hidden" with
semantics left up to the WM. So you could have your own concept
separate from shaded/minimized/desktop, maybe "zoomed out" or "docked"
or whatever, who knows.

With the WM spec, we've said "OK, IconicState no longer means whatever
the WM wants, it means minimized and only minimized, and we have a new
state of unmapped-but-NormalState for other kinds of taking the client
offscreen."

However, this new state is not detectable - when you unmap the
frame, the client doesn't get UnmapNotify.

You could say clients can monitor _NET_WM_STATE and
_NET_WM_DESKTOP. But they can only detect specific kinds of
hidden window that way, they can't detect some other sort of
iconification a WM may implement.

Anyway I think the ICCCM way of specifying this was forward-thinking
and allowed the clean implementation of new concepts such as desktops
and shading while still giving clients notification of state - but by
declaring the ICCCM IconicState to mean "minimize and only minimize"
you break that.

Also, you require all shaded/off-desktop windows to have a parent
frame so you can unmap them, right, even if the client is undecorated?
How do most WM's deal with that?

Don't know, in practice of course either way can be hacked around, I
just see minimize/shaded/off-desktop as logically equivalent flags,
and I interpret the ICCCM differently from whoever wrote those
sentences in the WM spec - as I read it, the intent of the ICCCM was
to make IconicState a state encompassing various ways to remove a
client from the screen, rather than one specific way. The only
rationale in the WM spec is that the client name isn't visible when
it's off-desktop, but this certainly need not be true, it can be in
pager tooltips, tasklist buttons, and menu entries, among other
places. And the client name definitely can be visible when shaded (all
current WM's display name not icon name, but they could certainly
choose to display icon name if it mattered).

Havoc