Re: ICCCM breakage, IconicState, and desktops

[Sasha_Vasko osca state mo us]

Hi

> Hi,
>
> The spec currently says this about implementing multiple desktops:
>
>  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 purpose of this paragraph was to outline 2 existsing alternatives,
with hidden idea to expose weakness of the second approach and convince
developers to go with the first one. And what you describe  in you letter
is another reiteration of the problem - In Order to change desktop without
"virtual root" one have to unmap out-of-desktop windows. But if you unmap
window - you have to change state to Iconic. Yet window is not in iconic
state and its icon window should be unmapped too. That leaves window in
undefined state. Thus such an approach should not be used by window
managers
to implement virtual desktops.

>
> The ICCCM explicitly and clearly contradicts this in section 4.1.4. It
> specifies that IconicState must always correspond to mapped/unmapped
> on the client window, and that the client window must be unmapped and
> set to IconicState whenever it becomes unviewable.
>
> The ICCCM description of IconicState is "whatever that means for this
> window manager." So I see no reason it can't be used for windows not
> on the current desktop, shaded windows, etc.

As per definition from 4.1.4 Iconic State means that either one of
icon_window,
icon_pixmap or WM_ICON_NAME is displayed/mapped. Which is clearly not the
case
for windows that aren't on current desktop.

One can argue forever about applicability of Iconic state to windows
that aren't on the current desktop, but there really is no need for it.
Much cleaner
way is to have "virtual root" windows  - one for each desktop, and simply
raise
"virtual root" whenever desktop become current. This approach gets rid of
the
Iconic state problem altogether.

Shaded windows cannot be in Iconic state as not WM_ICON_NAME, but WM_NAME
is displayed, and even more - client's main window will remain mapped.


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

waiting for MapNotify or UnmapNotify is incorrect way  of tracking
visibility. Correct way would be to wait for VisibilityChange events.
And when drawing is done directly in the window - waiting for Expose
events.


>
> We seem to have declared IconicState to mean "minimized" vs. all the
> other ways of taking a client offscreen (shaded, desktop, etc.)
> and to me this breaks the ICCCM in a way that was really not needed
> and doesn't make much sense.

Nope, we did not change meaning of Iconic state. Problem is that you cannot
apply definition from 4.1.4 of ICCCM to all those states. ICCCM appears to
be quite shortsighted in this regards.

> Can someone shed some light on what the rationale was here?
>
> The only issue I see with setting IconicState for not-on-desktop or
> shaded windows is that when restarting the WM it will minimize those
> windows, typically.

That is another problem, yes.

>
> To me it would make more sense if the spec left IconicState as-is in
> the ICCCM, and specified its use for any case where the client is
> unviewable. Then add a _MINIMIZED property to _NET_WM_STATE which
> would be used to track MINIMIZED as a special kind of iconification,
> alongside _SHADED which is already in _NET_WM_STATE.

Like I said we don't redefine meaning of Iconic state. We simply expose the
problem with particular implementation of virtual desktops ( which in fact
was used in some window managers ), so as to make window manager developers
aware of the consequences.

> On WM restart, the _NET_WM_STATE and _NET_WM_DESKTOP could be used to
> interpret the initial value of WM_STATE, i.e. indicating whether the
> initial IconicState means minimized/shaded/etc.


> Havoc


Sasha