Exiting Tkinter when using IDLE

[Jason Harper]

"Kurt B. Kaiser" wrote:
> When IDLE uses its subprocess, the intent is that there are two
> separate processes, each with a Tkinter application running.  One is
> the user's, the other is the IDLE GUI's.  This should work as well as
> the example in the previous paragraph.

Running a Tkinter app in the subprocess works, you just can't debug it
if it runs long enough to get into its mainloop.

> When IDLE doesn't use a subprocess, the user's Tk gets mixed with
> IDLE's, and it's not surprising things fail.
> 
> For me, on OpenBSD, Linux, and W2K, using the subprocess: if I use
> self.quit, the Dialog becomes unresponsive because the mainloop has
> been exited.  But the advertised action on mainloop exit is to destroy
> any remaining widgets, and that's not happening.  If I restart the
> shell, the Tk widget is destroyed correctly.

Where did you see that "advertised"?  quit() does nothing but cause the
innermost mainloop() to exit, and exiting a mainloop() does nothing
other than no longer processing events.  mainloops()s can be nested,
they CAN'T have side-effects like that!  If you exit without somehow
calling destroy() on all your toplevels, it's the OS's process
termination cleanup that kills the rest of them, as far as I can tell. 
And of course IDLE's subprocess doesn't terminate just because your
Python code finished.

It would appear that IDLE needs to detect that the user program is using
Tkinter (by importing Tkinter itself and overriding mainloop?), and in
that case switch to a different strategy for handling communication with
the main IDLE process - a routine that constantly reschedules itself via
after(), most likely.  The problem is the initial RPC request that runs
the user program: I'm pretty sure that the shell window is going to be
non-responsive until it receives the reply, which isn't going to happen
until the program exits.
	Jason Harper