[Idle-dev] Slow close?

[Stephen M. Gava]

We now have two threads on this subject: 'Re: [Idle-dev] Slow close?'
and, 'Re: [Idle-dev] "Jeff Hobbs": RE: Strange delays when using raise
or lower in KDE' , let's go back to just using the 'Slow close?' thread.

I just tested my proposed bugfix/patch to idle on a range of window
manager platforms that I have available and I can summarise the results
we have so far as follows:

Under ms windows and the following X window managers; WindowMaker,
BlackBox, Enlightenment, Sawfish (without Gnome): the problem never
existed, and the tcl/tk bug work-around of putting in an extra call to
lower() before the lift() has no ill effect. The other aspects of the
patch are still beneficial here because we now don't mess with edit
window stacking level or visibility unless we absolutely need to. 

Under Gnome/Sawfish, KDE and Oroborus/rootless X on Aqua: the problem
did exist; the benefits of the patch limiting the times the problem can
be triggered, mentioned above, mean that even without the extra lower()
work-around there will be less cases when the tcl/tk bug is triggered,
and so less cases where the user will notice a problem (ie there will
now only be a 'delay on closing' problem for edit windows that have
unsaved changes). 

The extra lower() successfully works around the delay on closing problem
in both the Gnome and X on OSX cases, however, on KDE only, it merely
changes the nature of the problem, making the pause occur after the
initial lower() instead.

I've had another good look through Tkinter.py (particularly the winfo_*
methods) and I still don't see any way of finding out if a toplevel is
already on top, so unless we get unexpected good news on that topic we
are really left with two choices in working around, or at least limiting
the problem, in the places we know it currently occurs: 

If the patch were applied to idle _without_ the work-around lower(),
then the pausing problem will be limited, on any platform it affects, to
occurring only when closing an edit window with unsaved changes.   

If the patch is applied _with_ the work-around then we know it solves
the problem in the Gnome and X on Aqua cases, but it also simply changes
the nature of the problem under KDE to one which I agree perhaps looks
even uglier.

Since it is likely that idle will continue to be run under tcl/tk <
8.3.4 for quite some time into the future I feel that at least the
minimal form of the patch (without the tcl/tk bug work-around lower())
should be put into python idle. Without that work-around the patch is
beneficial to idle's behaviour in all cases. I don't know whether
working around the problem under Gnome and X on Aqua is justifiable in
the light of the change in the nature of the problem it causes under KDE
or not. Anyone?

One important point that hasn't yet been addressed though is, since
tcl/tk 8.3.4 seems to be pretty unavailable (on linux at least) yet, has
anyone confirmed that the undesirable behaviour goes away with tcl/tk >=
8.3.4, epsecially under KDE??  

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