[Pythonmac-SIG] TK Issues, answer from mac-tk list

[Schollnick, Benjamin]

Jack (& Everyone else),

> First off, Tcl/Tk is not designed to allow you to load two independent 
> copies of Tk into an application.  There is global state in the 
> libraries that will cause conflicts.  So you have to make sure that you 
> unload the first copy completely before you try to load the second 
> copy.  You can create two tcl interpreters, both running Tk, but the way 
> you are supposed to do that is to create one interpreter, and then load 
> Tk into the second interpreter by running "package require Tk" in the 
> second interpreter.  This is, for example, how the console window in 
> MacTk works.  But we never intended you to be able to actually load the 
> Tk library twice.

> Theoretically, you could load Tk, then unload it. However, I never 
> worked very hard to make sure that you could unload Tcl/Tk from an app, 
> and then reload it again cleanly.  There are finalization routines for 
> all the subsystems, but I would have no problem believing they don't 
> clean up everything.  The only things I really cared about was 
> non-shared state, and resources that the system would not reap when the 
> process exited.  You could probably fix this - since the mechanism to 
> handle finalization is present.

We definetly have a difference between MacPython & Cpython here...

import Tkinter
test = Tkinter.Tk()
test2 = Tkinter.Tk()

On the PC, this will work fine...

On the Mac, it reports a Tcl/Tk Fatal error, and Panic's.... Locking up the
entire Macintosh (But it does allow a Force Quit)...

I now have an answer and can effectively code around this, but if we're
trying to allow platform indepence for our code, this may need to be
addressed.
At least now, we know it's a Tcl/Tk issue and not a MacPython issue (that
happens to occur in the Tcl/Tk code).

I haven't really examined the Python code in the Tkinter module to closely,
but....

>From what I see in the code, it each Tkinter.Tk() call creates a total new
interpreter, etc....  I'm not sure what we can do, to prevent this error
from occurring...

	* Patch the code, to prevent an 2nd initialization of the Tk
routines.
		That would involve creating a global counter in the Tkinter
module
		and incrementing / decrementing per initialization /
destroy.

	* Formalize a "shutdown" mechanism for Tkinter, that is called as
part
		of the initialization routine.  (To ensure any previous
Tkinter
		sessions are de-activated.)  The closest I could find was
the
		destroy command, but that appears to be a per window
basis...
		(How do you clean up after a Tkinter session?)

Either way, I see these "work arounds" causing code issues between the other
Tkinter/Python platforms. Sadly, I'm not versed enough in Tkinter to be
confident that any of these work arounds would be useful...

			- Benjamin