Re: ICCCM breakage, IconicState, and desktops

[Sasha_Vasko osca state mo us]

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

Ok, I don't want to get into the argument about what IconicState means, and
it really is not a concern of the paragraph in question. What this
paragraph
attempts to do is to a) recommend best way of virtual desktop
implementation
b) state the fact that some EXISTING window mangers implement it in some
different, possibly erroneous way, so application developers should be
cautious. As you see definition of the meaning of Iconic state is not at
issue
here.


So here is another wording Of the same paragraph :

<quote>

Implementation note

There are different way of implementing virtual desktops. This specs
recommends the following way :

For each virtual desktop special window has to be created which we'll
call "virtual pseudo-root". Every managed window (or its frame window)
must be reparented to become child of the virtual pseudo-root of the
desktop it is on.
When particular desktop is activated  - corresponding virtual pseudo-root
is raised in window hierarchy, thus obscuring other desktops. When
desktop is changed for particular window - its is reparented to the
corresponding virtual pseudo-root.

Application developers should be aware that there are Window Managers
that currently implement virtual desktops in different ways. One of the
known implementation is to simply unmap frame windows of clients that are
not on the current desktop. At the same time client window of such client
may or may not be unmapped and its WM_STATE may or may not be changed into
Iconic State. As the result application, while managed by such window manager,
may find itself in ambiguous state, when its windows are unmapped, yet
its WM_STATE has not been changed to Iconic.

</quote>

Accordingly paragraph titled "LARGE DESKTOPS" has to be moved to appear
right after this particular paragraph, and refer to "virtual pseudo-root"
instead of "virtual root"

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

Well, I hope this new wording fullfills this purpose.

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

When window is shaded only its titlebar is shown, which is usually a part
of
the frame window (some WMs don't do that  - I know).  So you have to keep
frame window mapped. If you unmap client window at the same time - you
enter
into another ambiguity that is not covered by ICCCM. While ICCCM clearly
states that if frame is unmapped - then client should be unmapped as well -
it does not say anything about if frame could be mapped, while client is
unmapped.

I'd think that it would be better to avoid possible ambiguity,
by solely relying on _NET_WM_STATE_SHADED to indicate that window is
shaded.

Another reason is that what shaded really means is left to decide to Window
Manager.
One of the possibilities is to reduce size of the client's window to some
smaller size.

On the other hand when you come to think why you need WM_STATE at all,
the only purpose is to let client know what it should animate - main
window,
or icon window ( 4.1.3.1 of ICCCM ). So there really is very little sense
in
changing window's state to Iconic if icon window is unmapped and
WM_ICON_NAME
is not visible. Think about it - application may use its title to display
some usefull info - when its in Iconic state - it changes WM_ICON_NAME -
otherwise
it changes WM_NAME. In such scenario changing state to Iconic, when client
is shaded and WM_NAME is visible - would cause us troubles.

Another scenario when we may get into troubles is when Window Manager
unexpectedly dies - all the windows with WM_STATE = Iconic will come up
as iconifyed when WM is restarted, which is clearly not the picture we want
to see for shaded windows. Thus we are better off not to change WM_STATE,
unless we really, really need it.

>
> Havoc

Sasha