#1337 cannot remove transient

[Mark G. Saye]

The following should make the toplevel .t
non-transient, but it retains some partially-transient
behaviour ( see http://wiki.tcl.tk/3542 )

toplevel .t
wm withdraw .t
update idletasks
wm transient .t ""
wm deiconify .t

Toplevel .t remains 'in front' or 'on top' of the main
window.. I see the same behaviour in 8.3.4 and 8.4.0 on
Linux, but not on Windows.

[Joe English]

Logged In: YES
user_id=68433

What window manager are you using (and what version)?

FWIW, I can't replicate the problem (tried various
combinations of metacity, Sawfish, 4DWM; and Tk
8.3.4/8.4/CVS HEAD). I can do a more exhaustive test on
Monday -- but chances are this is a WM bug, not a Tk bug.

If it's a bug at all. The truth is, the ICCCM makes no
guarantees at all about how transient windows should be
treated; just about any behaviour is allowed. If a
particular WM does something that makes Tk apps unusable the
core can try to work around it, but basically you shouldn't
expect [wm transient ...] to do anything specific.

[Mark G. Saye]

Logged In: YES
user_id=264793

This bug is only apparent with KDE 3.0.3 window manager
(kwin 0.95). Cannot replicate with enlightenment, blackbox,
xfce, icewm.

[Joe English]

Logged In: YES
user_id=68433

More info: [wm transient $w ""] sets the WM_TRANSIENT_FOR
hint to "None", instead of removing the property.

AFAICT, this is not legal according to the ICCCM (and the
consensus among WM authors seems to be that setting
WM_TRANSIENT_FOR to None, the root window, or the same
window is, although a fairly common practice, not quite right.)

However, the EWMH spec says:

"If the WM_TRANSIENT_FOR property is set to None or Root
window, the window should be treated as a transient for all
other windows in the same group. It has been noted that
this is a slight ICCCM violation, but as this behavior is
pretty standard for many toolkits and window managers, and
is extremely unlikely to break anything, it seems reasonable
to document it as standard."

(http://pdx.freedesktop.org/Standards/wm-spec/wm-spec-1.3.html,
section "Implementing enhanced support for application
transient windows").

So the behaviour you're seeing under KDE is actually the
"right thing" according to EWMH, and Tk is doing the wrong
thing. Raising priority...

[Joe English]

Logged In: YES
user_id=68433

Attached patch should fix the problem.

[Joe English]

Patch to unix/tkUnixWm.c r1.37, tests/unixWm.test r1.34

[Joe English]

Logged In: YES
user_id=68433

Patch comitted.
tests/unixWm.test : r1.34 -> r1.35
unix/tkUnixWm.c : r1.37 -> r1.38