As to wxPython, I'm afraid it just failed a test of some importance to
me. VPython does not run interactively from PyShell or PyCrust. It
just hangs. It does run interactively from the native prompt and from
the Idle prompt.
Hence my cc to the wxpython dev list, mentioning VPython, and the "would be
nice" prospect of integrating it more effectively.
Kirby:
I don't know it Patrick listens in here anymomre. You might want to
make the wxPython-dev folks aware of this issue. I wonder if it related
to the fact that wxPython *is* running over GTK and VPython is a GTK
window. Anywhere it's a bit disappointing.Art
Probably it's a deeper issue than Patrick tweaking his shell, which sits on
top of the wx library. I think getting VPython to show up in a wxWidget (a
window), and having mouse clicks go from VPython objects to the wx event
loop somehow, would require a lot of digging, a lot of legwork.
Or maybe the goal isn't to handle VPython window events (let VPython handle
its own events), but merely to support the orderly creation and destruction
of a VPython window, plus an ability to send wx events *into* VPython via
its native API (e.g. press a button on a wx frame, and watch every sphere in
a VPython window turn blue -- or we could have zoom-in/zoom-out buttons).
I don't have the expertise to code these things. However, the fact that
Vpython runs on Windows, Mac and Linux would make it philosophically
consistent with the wxWidgets aim. I can well imagine a VPython demo, right
near the OpenGL demo.
I don't know if the right way to handle integration with VPython is at the
C++ level, within wx, or at the wxPython level, or both. All I know is
Pygeo on wxPython would probably be really cool, interface-wise. And
keeping the VPython asset, vs. trying to redo it all in OpenGL, would likely
save many coder-years of time.
Kirby