[Edu-sig] How to explore Tkinter interactively with IDLE 1.0

[Guido van Rossum]

[resend, I wanted this to go to idle-dev but typed idle-sig]

> I just wanted to confirm what has been reported here regarding IDLE 1.0. 
> I have a simple 2D graphics package that I developed for CS1. It is 
> basically a thin wrapper over a TK canvas. With versions of IDLE prior 
> to 1.0, it was easy to experiment with the graphics interactively. Now, 
> that is much harder. The basic problem is that the eventloop in the 
> subprocess window is suspended when the IDLE interactive shell is 
> waiting for input. As has already been reported, judicious calling of 
> update() can be used to force the window to flush its queue. You can 
> call update() from the IDLE shell to force the window to react.
> 
> For example:
> 
>  >>>  from Tkinter import *
>  >>>  win = Tk()  # nothing appears
>  >>>  win.update()  # Tk window pops up
>  >>>  # now click in the close box of the Tk window, nothing happens
>  >>> win.update() # Tk window closes
> 
> The interesting thing is that events are getting posted even when the 
> window is unresponsive. As this example shows, the click in the close 
> box is carried out when the update() call is made.
> 
> Under Windows, subprocess Tk windows are completely unresponsive and 
> often pop up underneath the IDLE window.  If you drag the Tk window with 
> the mouse, nothing seems to happen, but typing win.update() in the shell 
> will cause the Tk window to jump to the new location. Under Linux, the 
> situation is slightly better, the window is still under control of the 
> window manager and can be moved and resized, but Tk events do not occur 
> until an update().
> 
> My partial solution to this problem has been to add updates() to my 
> library. But realistically, if you want to do interactive 
> experiementation with Tkinter, the DOS or Linux command line is the 
> better route now. It would be nice if this could be fixed, but I'm 
> willing to give this up for the other features introduced by the IDLE fork.

This is because under IDLE 1.0, Tkinter programs don't get to benefit
from IDLE's Tkinter mainloop.  Tkinter programs written for use
outside IDLE runs fine under the new IDLE, because such programs
already have an explicit call to the Tkinter mainloop (otherwise they
wouldn't function at all).  Under IDLE 0.8, such programs, once started,
would be hard to stop because their mainloop and IDLE's mainloop would
compete.  But interactively playing with Tkinter has become harder.

So, the new IDLE, conforming one of its design goals, has actually
become more compatible with Tkinter applications -- but at the same
time the unique IDLE 0.8 feature of easy interactive Tkinter
experimentation has gone out of the window.

A work-around is to use the -n command line argument to idle (a bit
tricky to invoke on Windows but you should be able to add this to the
IDLE alias or create a batch file for it), which runs the Python code
in the IDLE process as in IDLE 0.8 (with all the risks of that mode,
like losing data in IDLE when the app crashes or hangs).

Perhaps this could be made a more easily configurable option (a
checkbox or radio button in the General configurations dialog would
seem the right place).

Do we need something else?  Perhaps some trick that you can invoke
that runs a Tkinter mainloop in a background thread?  (But note that
Tkinter and threads don't go well together.)

--Guido van Rossum (home page: http://www.python.org/~guido/)