[Edu-sig] re: Pygeo, platforms, wx and Tk

[Arthur]

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