Re: ICCCM breakage, IconicState, and desktops

["Sasha Vasko" <sasha aftercode net>]

----- Original Message -----
From: "Havoc Pennington" <hp redhat com>
To: "Sasha Vasko" <sasha aftercode net>
Cc: "Olivier Chapuis" <olivier chapuis free fr>; <wm-spec-list gnome org>
Sent: Sunday, December 02, 2001 6:19 PM
Subject: Re: ICCCM breakage, IconicState, and desktops


>
> "Sasha Vasko" <sasha aftercode net> writes:
> > Not really simple. Firstly that does not resolve the problem with
ambiguous
> > state of unmapped windows, since there is sugnificant number of
applications
> > out there that relay on ICCCM compliant IconicState, so even if you
unmap
> > window without setting _NET_WM_MINIMIZED, they will still consider self
> > iconifyed and start animating its icon window, instead of normal
> > one.
>
> IconicState is defined in the ICCCM to be ambiguous. The ICCCM says

Ok, I see thre points emerged from this discussion :

1. Addition of _NET_WM_STATE_MINIMIZED atom in order to provide
Pagers and likes with enough data to handle minimized windows correctly.

2. Recommendation of virtual-root vs. non-virtual root approach to virtual
desktops

3. Using _NET_WM_STATE_MINIMIZED in order to make non-virtual-root
implementation nicer.

Trouble with _NET_WM_STATE_MINIMIZED is that it does not have clear
meaning ( just like IconicState). Client could be minimized in many
different ways -
to client's provided window; to pixmapped Icon; to smaller titlebar
containing
WM_ICON_NAME text, etc. It could be placed anywhere and it could belong to
different desktop, or even be sticky. All of this information is essential
for Pagers
and others to be able to handle minimization gracefully, yet simply adding
_NET_WM_STATE_MINIMIZED to _NET_WM_STATE we do not provide
any of that info. This makes it even more useless then WM_STATE property,
since
WM_STATE at least provide icon window ID in addition to state value. The
only
thing it would be usefull for is for non-virtual-root implementation. Such
lack of value was the exact reason why I'm objecting it. Now lets think
about how
we can change it.
We could add one more property to the client window in order to clarify
parameters
of minimized window. Lets call it _NET_WM_MINIMIZED_STATE. Since we
need to make it hold such a wealth of information, it has to have rather
complex
structure :

_NET_WM_MINIMIZED_STATE[0] - icon position x value
_NET_WM_MINIMIZED_STATE[1] - icon position y value
_NET_WM_MINIMIZED_STATE[2] - icon width
_NET_WM_MINIMIZED_STATE[3] - icon height
_NET_WM_MINIMIZED_STATE[4] - icon desktop
_NET_WM_MINIMIZED_STATE[5] - icon window (if any)
_NET_WM_MINIMIZED_STATE[6] - icon pixmap (if any)
_NET_WM_MINIMIZED_STATE[7] - icon pixmap mask (if any)
_NET_WM_MINIMIZED_STATE[8...] - arbitrary set of atoms that describe
minimized state :
_NET_WM_MINIMIZED_ICON_NAME - value of _NET_WM_ICON_NAME
is visible
_NET_WM_MINIMIZED_NAME        - value of _NET_WM_NAME is visible
_NET_WM_MINIMIZED_HIDDEN     - there are no icon displayed at all

Window managers can add aditional atoms here to suit their needs.

Now that would clearly be usefull and with such an addition I would
whole heartedly agree to add _NET_WM_STATE_MINIMIZED.
But adding this atom for sole purpose of fixing non-virtual-root approach
I find rather unhealthy.

Now on to the second and third items :
I don't see the wording in specs at present time as prohibiting
non-virtual-root
approach, It simply states possible pitfall with unmapping frames.
Actually we could improve this paragraph by compiling a list of advantages
of each approach, so that ppl could make informed decision.
Now, if we are to add _NET_WM_MINIMIZED_STATE, then even
last part about iconifying off-desktop clients could be amended,
but adding _NET_WM_MINIMIZED_STATE for the sole purpose
of resolving this is unwarranted, since it would simply overlap
IconicState without providing any additional info.
We need to add more value to it.


> (section 4.1.4) that the "top-level window is iconic (whatever that
> means for this window manager)" and that WM_ICON_NAME can be displayed
> instead of icon_pixmap or icon_window. Moreover, the EWMH spec already
> implicitly discourages the use of icon windows and even icon pixmaps;
> that's why we have the RGB format icons. Under both GNOME and KDE,
> icon windows and pixmaps get totally ignored, pretty much, especially
> if an RGB format icon is available.

right, but icon windows still have its value, since it may provide user with
some
usefull changing info even when window is iconified, instead of displaying
some static icon. Consider terminals with tail running in them, for example.

> Essentially, icon windows and pixmaps are deprecated, because they
> can't be scaled, and the window can only be displayed in one place at
> a time. So they don't work very well.
>
> So, I don't think animating the icon window is in any way an issue.  I
> don't think the ICCCM guarantees a viewable icon window in
> IconicState. If it does, we can always put the icon window offscreen
> somewhere and ignore it, but GNOME/KDE do not at present do that,
> regardless of the outcome of this discussion. So no apps are going to
> rely on the icon window being viewable.

apps don't rely on it, but some users will be wanting to get this piece of
functionality, and frankly I'm suprised that GNOME/KDE such blatantly
reject it.

> > From the other hand, what would be the meaning of the state when
IconicState
> > is set but _MINIMIZED is not ? Its not good to override existing
properties
> > with new ones.
>
> MINIMIZED does not override IconicState. What I was arguing for
> previously, and Olivier is bringing up, is that IconicState in the ICCCM
> just means "any state in which the window is unmapped, as defined by
> the window manager."
>
> If you read on in section 4.1.4 in the ICCCM, it says:
>
>  "In fact, the window manager may implement states with semantics
>  other than those described above. For example, a window manager might
>  implement a concept of an 'inactive' state in which an infrequently
>  used client's window would be represetnted as a string in a menu. But
>  this state is invisible to the client, which would see itself merely
>  as being in the Iconic state."
>
> So in fact the ICCCM _explicitly_ says that you can put a client in
> IconicState but NOT display its icon window and NOT have the client
> "iconified."
>
> IconicState has NEVER been equivalent to minimized. The ICCCM simply
> defines it as any state where the client window is unmapped. The
> strong guarantees made in the ICCCM are about the relationship of
> map/unmap/withdrawn to IconicState/NormalState/WithdrawnState, the
> ICCCM makes ZERO guarantees about what IconicState _means_ or whether
> the icon window or icon pixmap gets displayed. Even if it did, as I
> said we've basically already punted iconification and
> icon_window/icon_pixmap in favor of minimization and task lists or
> window menus.
>
> The purpose of a MINIMIZED state is to tell pagers a specific _reason_
> why a given window is in IconicState, vs. other possible reasons the
> window may be in IconicState. MINIMIZED is not replacing IconicState,
> it is complementing it by specifying additional information/details
> about the window's state. This information is NOT currently reliably
> available, using the ICCCM and EWMH as written.

Right by as I said it does not convey little usefull info besides that,
since
minimization's semantics are rather undefined.

> > The disadvantages of putting windows in ambiguous state by unmapping
> > only frame, is rather minor thing when compared to adding whole new
> > property that overrides existing one.  AS I said before specs does
> > not make approach of unmapping frame illigal, but, simple state
> > dangers of it. Maybe the wording has to be changed to avoid
> > confusion.
>
> Because the spec lacks the MINIMIZED state, it does require you to use
> IconicState only to mean minimized, not for any other purpose. Which
> means you must violate the ICCCM if you want to unmap a window for any
> purpose other than minimization. And there is simply no reason we need
> to introduce this ICCCM violation or restrict window managers in this
> way.

Just out of curiosity, what could be the reason to unmap client window ?

> If your window manager only uses unmapping to mean minimization, then
> adding the MINIMIZED state means you have to change exactly TWO lines
> of code, to set/unset _NET_WM_STATE_MINIMIZED when you set/unset
> IconicState. That is really, really easy - I don't see why you are
> opposed to it. I don't see why forcing ICCCM violations is a better
> alternative. What is the harm to adding those two lines of code?

There is no harm whatsoever, like I said - as proposed, it would not really
provideany additional information over WM_STATE, and as such makes
little or no sense. Adding two lines is easy, but loitering specs with
useless
atoms and having to live with that for the rest of your life is tough.

> > Unmapping both client and frame without need has other
> > disadvantages, for example, if both frame and client are unmapped
> > and window manager crashes - when it restarts, it may confuse such a
> > client with withdrawn, since all of it windows will be unmapped.
>
> Are you sure? According to the Xlib manual:
>
>  "If the window manager dies, all windows listed in the save-set will
>   be reparented back to their closest living ancestor if they were
>   reparented in the first place and mapped if the window manager has
>   unmapped them"

well, ok my bad here.

>
> Also, the ICCCM requires unmapping the client window if you unmap the
> frame.

yes it does, althou I would really like to get a clarification from Mr.
Rosenthal
as to what the heck it was required for.

> Havoc

Sasha