modal windows vs. WM_TRANSIENT_FOR

[Matthias Clasen <maclas gmx de>]

The EWMH currently requires that apps break the ICCCM for group-modal
windows by putting the root window in WM_TRANSIENT_FOR (which is not a
toplevel window, as required by the ICCCM).

It seems that this (setting WM_TRANSIENT_FOR to root) is a bug in old
gtk versions which has found its way into a standard. 

Reading up what the ICCCM says about WM_TRANSIENT_FOR:

The implication is that this window is a pop-up on behalf of the named
window, and window managers may decide not to decorate transient windows
or may treat them differently in other ways. In particular, window
managers should present newly mapped WM_TRANSIENT_FOR windows without
requiring any user interaction, even if mapping top-level windows
normally does require interaction. Dialogue boxes, for example, are an
example of windows that should have WM_TRANSIENT_FOR set.

I think most of these uses are covered better by the EWMH semantic types
by now. One thing where WM_TRANSIENT_FOR is still needed is placement
relative to the transient parent, the other is modality wrt to a 
dedicated parent, not the whole group. I think we should try to clarify
this in the EWMH and rewrite the explanation of _NET_WM_STATE_MODAL
along the lines of

"If the WM_TRANSIENT_FOR hint is set to another toplevel window, the 
dialog is modal for that window; if WM_TRANSIENT_FOR is not set or set
to the root window the dialog is modal for its window group."

This has the advantage that we no longer require apps to break the ICCCM
for group-modal windows, but still support the WM_TRANSIENT_FOR=root
dialect.

Matthias

PS: recent versions of gtk will set _NET_WM_STATE_MODAL even if
WM_TRANSIENT_FOR is not set; see
http://bugzilla.gnome.org/show_bug.cgi?id=100416