[Idle-dev] "Jeff Hobbs": RE: Strange delays when using raise or lower in KDE

[Stephen M. Gava]

Guido van Rossum wrote:
> It appears a Tcl bug, fixed in Tcl 8.3.4.

Ah, since I was working under Gnome/Sawfish, and Gnome/Sawfish,KDE and
Ouroboros/rootless X on Aqua, were the only places the bug could be
reproduced, it didn't occur to me to re-test on KDE as I was thinking
that it must be the same problem...  My own testing on Gnome/Sawfish and
Bruce Sherwood's testing on X on OSX confirm that the workaround I
discovered of putting in an extra lower() works in those two out of the
three known problem domains, but I just ran it on KDE here (I have
tcl/tk 8.3.3 installed) and can confirm also that the problem still
appears on KDE alone.

So it appears that the final fix for the underlying problem in tcl/tk
may the only answer under KDE (unless there is a way to test whether a
toplevel is at the top of the window stack in tkinter, see later in this
message for details).

I still feel that the changes to EditorWindow closing I came up with are
useful to consider including in python idle (I think I will leave the
changes in idlefork) for the following reasons: firstly; making the
fiddling around with window focus only occur if absolutely nescessary,
ie. if we are closing an editor window that has unsaved changes and only
deiconfy()'ing if required, is a much cleaner implementation, and
secondly; putting in the extra call to lower() works around the
'freezing' problem on both X on OSX and on Gnome without ill effect.

It may be that the fix in tcl/tk 8.3.4 obviates the need for that extra
lower() in X on Aqua and Gnome too, but that doesn't change the fact
that idle will be being run on those platforms under tcl/tk < 8.3.4 for
quite some time into the future and it would be nice if there at least
this simple trick could save people from that problematic behaviour.

It may still also be possible to provide a work around for people using
KDE with tcl/tk < 8.3.4 too. I never could find a way in tkinter to test
wheter a toplevel was already at the top of the stack of open windows,
if there is a way to test for this then the

lower()
lift()

can be changed to 

if (window at top of stack test returns true):
    lift()

which would most likely work for kde too since your tcl/tk tests there
confirmed my suspicion that it is lift()'ing a toplevel when it isn't
required that triggers the problem in the first place.

So, Guido, do you have any exalted tkinter experts on tap the way you do
with tcl/tk experts?  8^)   If you do, and they know a way of testing
for such a condition under tkinter, then we can extend the workaround
for Gnome/X on Aqua users with tcl/tk < 8.3.4 to KDE users with tcl/tk <
8.3.4 too.

Stephen.
-- 
Stephen M. Gava  <elguavas@users.sourceforge.net>
IDLEfork ( http://idlefork.sourceforge.net )  " just like IDLE, only
crunchy "