Re: ICCCM breakage, IconicState, and desktops

[Havoc Pennington <hp redhat com>]

Sasha_Vasko osca state mo us writes:
> 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.

This is where I disagree with you - I read the ICCCM as implying that
any kind of taking the window offscreen can be considered
IconicState. You're arguing that IconicState == minimized, I don't
think that's accurate, though obviously it is the traditional
implementation of IconicState.
 
> 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.

It doesn't say IconicState means that. It says IconicState means
"whatever it means for this WM" and that the client can expect icon or
icon name to be displayed in some way.

As I mentioned previously, windows on other workspaces may have their
name displayed in menus, in tasklists, in pager tooltips, and so
on. But even if they didn't, I really don't think display or
nondisplay of icon name is the primary definition of IconicState.
Especially since I can't think of a single client that depends
crucially on its icon name being visible.

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

My point really isn't specific to desktop switching. What I'm really
worried about is a) the equation of IconicState to minimize and b) the
spec seems to recommend this unmap-frame-but-not-client-window thing.

I'd like to change the language of the spec to at least make it clear
that you shouldn't do b), even if I can't convince people of
_NET_WM_STATE_MINIMIZED.

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

Client's main window certainly doesn't need to be mapped for shaded
windows. You could leave it mapped, sure, but there's no real
requirement to do that. Shaded can be a way to iconify a window.

Havoc