Exiting Tkinter when using IDLE

[Jason Harper]

"Kurt B. Kaiser" wrote:
> Using IDLE w/subprocess, set a breakpoint (right click) on 'print "quitting"',
> Turn on the debugger, then Run/F5 this program. Click on 'Go', then
> the apps' QUIT button.  The debugger will break on the print
> statement.  You can then Step into Tkinter. The last line in the
> debugger window is
> 
> > 'Tkinter".quit(), line 968: self.tk.quit()
> 
> So this is working as I would expect.  The debugger only traces Python.
> 
> Maybe I don't understand what you mean by "debug".

In a non-subprocess IDLE, you don't have to hit a breakpoint to be able
to examine a running Tkinter program.  Both the shell window and the
user program are fully responsive at the same time.  For example, you
could type a command to change the appearance of a button, and
IMMEDIATELY try out the button with its new appearance, since the
mainloop is still running.  This ability is lost in a subprocess IDLE.

> > 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,
> 
> What would be the application?  I've never tried that.

Modal dialogs.  If you need an answer from the user right now, before
anything else is done, you can create a new toplevel and allow
interaction with it via a nested mainloop (or more likely, something
that internally calls mainloop(), like wait_window() or one of the
standard dialog routines).
	Jason Harper