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

[Kent Johnson]

Thanks for the explanation. I didn't realize that the two panels are using different GUI frameworks. 
I don't know how to make that work...

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
> 
> 
>