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