I had written -
Bottom line problem is that I am using threading without understanding threads. I'm guessing my answer is somewhere in getting down a level into the threads themselves, rather than trying to get away with only dealing at the level of the objects being threaded.
And now that I have a real problem to solve, I'll probably get down there (eventually) and solve it
Was able to spend some time on this today. Explored what I could find about threading and Tk, and learned (I think) - among other things - that the problem I was running into seems to (somewhat ironically) be the result of tcl implementing threading in 8.4 (and that the reason it was not cropping up on Windows is not a os issue, I'm thinking, but that tcl/tk is compiled on Windows without threading support) Whether the above is right or wrong ... I seem to have found a simple solution without going deeper in an implementation of threads, and qeues, and locks and semaphores and such. I start the TK thread from the VPython GTK Display class, sending "self" as a parameter to the Tk ControlPanel class. No problem here, as long as I don't try to start the TK mainloop from here. The Tk ContolPanel now has a reference to the Display and can send messages through that reference. The mainloop() call is from within __init__ of the Tk Control Panel. I had gotten that far before. Turns out, to get my bi-directional communication, all I need to do is setattr(Display,"control_panel",self) in the __init__ of the Tk ControlPanel class, so that now Display has a reference to the ControlPanel by which it can send messages of its events back in that direction. My first ever use of setattr. Knew it was there for something ;) Tidy and simple, I think. And I *do* have fun with Python. Art