[Visualpython-users] Progress toward wxPython

[Bruce S. <Bru...@nc...>]

Some time ago I mentioned my intention to build a version of VPython
that uses wxPython to create the window, establish an OpenGL context
in that window, and handle keyboard and mouse events. This would make
it possible to discard the existing three platform-specific C++
components for dealing with these tasks (Windows, Macintosh, Linux),
because wxPython, based on wxWidgets, is platform-independent.

The need for this is somewhat urgent, because the Mac version of
VPython is based on the Carbon framework, which is no longer fully
supported. In particular, Carbon cannot be used with 64-bit
applications (one must use Cocoa), which means that at the moment it
is impossible to build a native-Mac (not Unix) version of VPython for
the Mac that can run with a 64-bit version of Python, and until very
recently there seemed to be no way to base VPython on Cocoa, for
technical reasons (see below).

I'm pleased to say that I've managed to get a basic wxPython-based
version to work, with the platform-specific C++ components replaced by
pure Python code. There are many remaining details to deal with, but
I'm able to display an animation, and to rotate and zoom the scene.
Progress.

Looking ahead, here are some comments about what a wxPython-based
version of VPython will look like.

First, it is likely that all animations will have to contain a rate or
sleep statement. This is due to a very technical issue. Cocoa requires
that Cocoa itself be the primary thread, whereas the current VPython
makes Carbon be the secondary thread. To turn this architecture
inside-out required some fancy footwork, and the summary statement is
that the visual module and your user code are likely to be in a single
thread, with no multithreading. This simplifies the VPython
architecture, but requires the user to use rate (or sleep) to allow
VPython to render the scene periodically. Without a rate statement in
an animation loop, nothing will appear on the screen until you exit
the loop, and then you'll see only the final state of the display. I
judge that the need for rate isn't serious, because almost all
animations necessarily contain a rate statement anyway, to make the
animation run at a roughly machine-independent speed. Experience with
GlowScript (glowscript.org), which also requires use of rate (because
JavaScript doesn't have threads), suggests that requiring a rate
statement isn't a significant burden.

Second, it should be possible to place a 3D animation anywhere in the
window, place other wxPython widgets in the same window (e.g. buttons,
sliders, text, etc.), and create normal pull-down menus for the
window. This suggests that VPython should have two new objects, a
"window" object (to hold menus and the various widgets), and a
"canvas" object (to provide the OpenGL context for the 3D animations.
The existing VPython "display" object would remain as a device that
creates a "window" object and places a "canvas" in the window in such
a way as to fill the window, as is the case currently.

Third, there currently does not exist a version of wxPython for Python
3.x, just 2.x, but on May 24, 2012, there was news that this is
forthcoming:

   http://www.blog.pythonlibrary.org/2012/05/24/wxpython-for-python-3-is-almost-here/

Fourth, presumably the new VPython will have the version number 6.00,
to emphasize a change in the definition of VPython, namely the
necessity to use rate in animations.

Bruce Sherwood