Subject: About the tk raise problem

From: Matthias Clasen <[email-masked]>
Date: Thu, 3 Jun 1999 14:32:40 +0200

I found out that tk is doing a ReconfigureWMWindow and then waits for a
ConfigureNotify. It tries to be very clever by guessing if the wm will
actually configure the toplevel or the frame and does wait for the notify
on *that* window only if the guess is yes.

This behaviour of TK is not 100% ICCCMly correct, however, since the wm may
well decide to ignore the ConfigureRequest. The ICCCM requires the wm to
send a synthetic ConfigureNotify in this case, which we do. But the synthetic
event will always arrive on the toplevel, not on the frame, where tk looks
for it... this is what is causing the delays you have noticed. As a
workaround,
I have added code to send another ConfigureNotify on the frame.

Analysing all this, I noticed that the code for sending the synthetic
ConfigureNotify is in SetupFrame (old twm heritage), and thus we create
lots of useless ConfigureNotifys. I have moved the code to
HandleConfigureRequest, since we only need to generate synthetic
ConfigureNotifys in response to ConfigureRequests. The sendEvent parameter
of SetupFrame is now defunct and I will remove it from all callers, if nobody
steps forward with a good argument for keeping it.

-- 
Matthias Clasen, 
Tel. 0761/203-5606
Email: [email-masked]
Mathematisches Institut, Albert-Ludwigs-Universitaet Freiburg
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]