[Tkinter-discuss] Modal dialog behavior

Jeff Epler jepler at unpythonic.net
Tue Mar 22 22:20:49 CET 2005


I took a look at the source and CVS history of some related files in Tk
(dialog.tcl and tkUnixWm.c).  It could be due to the addition of
'WmWaitMapProc':
    http://cvs.sourceforge.net/viewcvs.py/tktoolkit/tk/unix/tkUnixWm.c#rev1.21
    http://cvs.sourceforge.net/viewcvs.py/tktoolkit/tk/unix/tkUnixWm.c?r1=1.20&r2=1.21
If this is the case, you can't really do anything about it in
Python/Tkinter, because this is low-level stuff whose details are all
internal to Tk.  You can write your own code that steers clear of 'wm
transient', but this is really the only way to enforce the stacking
order between your application and its pop-up, too.

Having looked at this code, re-read the section on 'wm transient' in the
wm manpage, and the ICCCM text on WM_TRANSIENT_FOR[1], I'm not sure what to
think.  On the one hand, the window manager is supposed to build
whatever behavior it likes on WM_TRANSIENT_FOR.  The Tk documentation,
on the other hand, has a muddled explanation about how this is for "e.g.
pull-down menu" which is not at all what WM_TRANSIENT_FOR is about---a
common misconception explicitly mentioned in ICCCM

The Tk documentation says 'A transient window will mirror state changes
in the master and inherit the state of the master when initially
mapped.' (which I would have said is something the window manager is
supposed to manage, as far as X is concerned---and something that
icewm+tk8.3 seems do just fine!).  So when your window manager
implements desktops by withdrawing windows not on that desktop, you can
get behavior like you saw in icewm:
    0. Master on desktop 1, desktop 2 is visible.  New window is mapped,
       transient for master
    1. Master is not mapped, so transient is unmapped by WmWaitMapProc
    2. User switches to desktop 1, so WM maps master.  Tk maps transient
    3. Wm switches to desktop 2 to show transient, unmapping master
    4. Tk unmaps transient because master was unmapped
This sure looks like an unintended consequence/interaction of Tk's 'wm
transient' and your window manager's implementation of
desktops/workspaces.

You may want to pursue this on a Tk newsgroup/mailing list, armed with a
simple Tk-only program that shows the problem with the various window
managers.

Jeff
[1] http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.2.6
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.python.org/pipermail/tkinter-discuss/attachments/20050322/28f2e98a/attachment.pgp


More information about the Tkinter-discuss mailing list