Re: ICCCM breakage, IconicState, and desktops

[Sasha Vasko <sasha aftercode net>]

On Tuesday 04 December 2001 06:32, Matthias Clasen wrote:
> Let me try to understand what exactly is proposed here to avoid a conflict
> with the ICCCM:
>
> WMs are encouraged to put windows which are unviewable because they are on
> other desktops in IconicState, but not add _NET_WM_MINIMIZED to
> _NET_WM_STATE. Windows which are unmapped because they are iconified,
> shaded, minimized, etc on the other hand, are put in IconicState with
> _NET_WM_MINIMIZED added to _NET_WM_STATE, right ?

If client is put into IconicState it serves as an indication that client 
should animate its icon window and WM_ICON_NAME. It is widely used feature in 
practice. Especially animating WM_ICON_NAME. For example in terms, there is 
an escape sequence for changing term's title, which gets displayed in 
WM_ICON_NAME if term is in IconicState. Web browser will display download 
progress in WM_ICON_NAME when its in IconicState. And lots more uses for it. 
Naturally ICCCM does not guarantees that it will be viewable, but it does 
state that WM_ICON_NAME should be animated instead of WM_NAME when window is 
in IconicState. And Window Manager should do its best to actually display 
this data, unless otherwise required by its policies. Its usefull service and 
lots of users swear by it.

Now what happen when you change window into IconicState, while switching 
desktops? Client will assume that it should animate its WM_ICON_NAME and will 
proceed to do just that. Yet taskbar/Pager/whatever will still be displaying 
WM_NAME, since it awaits _NET_WM_MINIMIZED. AS the result you will get a mess 
- download progress for off-desktop browsers will be frozen, term's title 
changes will not be displayed in taskbar and user will get rather pissed off. 
To avoid that you should start displaying WM_ICON_NAME, despite the fact that 
window was not really minimized, but merelly moved off-desktop. Essentially 
you have to display window as minimized, even thou _NET_WM_MINIMIZED is not 
set. What is the value of _NET_WM_MINIMIZED in such context let me ask you ?
None whatsoever.

What you really want here is to add one more window state here that does not 
relate to IconicState whatsoever. In fact it could be used with NormalState 
as well. Basically you have to state that : 
1) Iconic/NormalState governs which of two client windows should be mapped ( 
if any at all ) and which of WM_NAME/WM_ICON_NAME should be diplayed in 
various places.
2) WE want to add additional state that has no connection to IconicState 
whatsoever, and governs HOW active client's window is displayed (one of two 
iconic/normal as governed by WM_STATE ).  So for example if client is in 
NormalState, yet _NET_WM_MINIMIZED is set we should display WM_NAME and 
smaller version of normal client's window. 

Now what is the exact semantics of this new state, nobody was able to tell 
exactly so far. My perseption is that it is almost identical to what 
IconicState was considered to be. And IMHO introduction of this state will 
cause nothing but confusion among application developers, with something like 
the following occuiring in their monds : 
" Oh, nice, now I have two minimized/iconic states! How the hell am I 
supposed to know whether I should send ClientMessage to get into IconicState, 
or _NET_WM_STATE one, to get into _NET_WM_MINIMIZED one? Or both ?
And whichever of two Normal state I should request now ? With 
_NET_WM_MINIMIZED or without ? How am I supposed to know what exactly WM will 
do in _NET_WM_MINIMIZED state ???"

Clearly you get a case of clashing semantics. 
What harm does it do to unmap window's frame without unmapping client and 
changing it into IconicState ? None whatsoever. This practice has been around 
forever and nobody even noticed it. What impact would be of adding 
_NET_WM_STATE atom with overlapping semantics with IconicState ? Much greater 
impact and inconvinience. You should be practical here and go with less 
painfull solution.

If you really want to be able to specify what exactly was the reason for 
changing into IconicState - then add another property that would not be 
modifyable by client in any way. Do not pollute _NET_WM_STATE with it.
I
> Pagers can then skip iconified windows by looking for _NET_WM_MINIMIZED,
> not for IconicState.

They will still need to display WM_ICON_NAME instead of WM_NAME wich is 
part of being iconic.

> If this is really the proposal, I'm in favour of it - even though I wrote
> the introductory paragraph
> about IconicState for windows on other desktops being unacceptable. After
> thinking a bit about it,
> the main reason why it is unacceptable is that pagers and other wm
> appendages which rely exclusively
> on IconicState will not cooperate perfectly. But one of the main aims of
> the EWMH is to enable
> better cooperation between wms and such tools *if both sides support the
> EWMH*.  And it won't

Its not the matter of both sides supporting EWMH, its the matter of clashing 
semantics.

> even be a problem for tools using private communication channels to the wm,
> like the fvwm pager.
>
> Matthias

Sasha