Kent
Arthur wrote:
Kent writes -
Arthur wrote:
So I have 2 windows - one is a Display for the VPython rendering and is actually constructed as a class derived from the VPython display object (native on Windows, GTK1 on linux) The other is a TK control panel.
The user can interact with either - pick and move points, for example,
in
the Display, or reveal or hide construction levels from the control
Panel.
So each must be in a loop, and the 2 windows need to be able to
communicate
with to each other as to any user action.
I don't understand what the loop is doing. It sounds like you are polling the panel for changes instead of using event callbacks and the GUI event loop.
Maybe you know this - normally in a GUI application you register callback handlers with the widgets in the gui. So when a field changes a handler function is called to do whatever you want. No explicit loop is needed.
I am not sure what you are saying. By "be in a loop" I think I am referring to the same GUI event loop to which you are referring. My TK "loop" is nothing but the GUI event loop, using the event callbacks,
You certainly should be able to create a GUI app with two panels that respond to user input without explicitly creating any threads.
I think I understand that this is trivial, when the two panels of the GUI app are using the same GUI toolkit. That is specifically the kind of thing that GUI toolkits are designed to handle, and why Aahz asks why someone would want to multi-thread a TK application.
And the fact is I don't want to multi-thread a TK application. What I want is a single TK thread and a single GTK thread, and the capacity to communicate between them, bi-directionally.
Well, this is not really what I want;) But it is the problem that the circumstances put on my plate, as I am interpreting the circumstances and the problem.
How could I have 2 windows from 2 different windowing toolkits, each responsive to user interaction, without running them as separate threads?
Then I have also heard it said, as an opinion, that threading is usually the wrong solution for communication between processes. But when we get into to the distinction between separate processes and separate threads, I am in territory with which I am unfamiliar.
The problem of running the old IDLE with VPython was, I think, one of making room for two processes, rather than 2 threads to run, without interference. And it was solved. Using sockets? But then, in this case, no input to IDLE needs to be handled *while* a VPython window runs. So I think my problem is distinguished.
All that said, I am not *convinced* that there is not a trivial solution here. The solution on Windows is trivial enough. But my assumption that it was a crossplatform solution, at least as to the specifics of my implementation, was apparently na�ve.
Art
_______________________________________________ Edu-sig mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/edu-sig
