On Sun, 2004-08-01 at 10:05, Arthur wrote:
> Jonathan, Bruce -
>
> Thanks for the efforts that brought us VPython 3.0!
>
> What I am most excited about is the ability to now subclasss cvisual classes
> directly in Python.
Well, you might find that that is dangerous since most of the
cvisual.foo objects are incomplete, and the balance of what is
implemented in C++ vs what is implemented in Python is subject to
change.
Note that cvisual.foo objects are written entirely in C++, and don't
export the complete API specified by Visual's documentation. The
visual.primitives.foo objects extend the cvisual.foo objects to complete
the API in some of its more "Pythonic" ways (like variable-length
keyword argument constructors, for example).
> Since the facility is undocumented at this point, I
> thought I'd bring it to the attention of the community of VPython users.
>
> A trivial example, of a complete scene with a sphere that defaults to being
> blue, instead of the VPython standard white:
>
> import cvisual
> import time
> import atexit
>
> def __waitclose():
> while not cvisual.allclosed(): time.sleep(0.05)
> atexit.register(__waitclose)
>
> scene = cvisual.display()
>
> class bluesphere (cvisual.sphere):
> def __init__( self,*args,**keywords):
> cvisual.sphere.__init__(self)
> self.color=(0,0,1)
> self.complete_init( self, self,
> 1, scene, None)
> bluesphere()
>>> obj2 = bluesphere()
>>> obj2.pos = cvisual.vector(1,1,1)
>>> # The sphere didn't move!
Therefore, it is a much better idea to inherit from the
visual.primitives.foo or visual.ui.display objects, manipulate
**keywords as you see fit, and then call the parent's __init__()
method. Here is a much simpler implementation of the "force to blue for
sphere's only" policy that doesn't rely on any internal API's, and
includes the complete API for Visual's sphere objects:
import visual.primitives
class bluesphere( visual.primitives.sphere):
def __init__(self, **keywords):
keywords['color'] = (0,0,1)
visual.primitives.sphere.__init__(self, **keywords)
> I would hope that an eventual documentation of the API for subclassing from
> cvisual (and perhaps some refinement of it) will unleash the VPtyhon
> community's creative exploration of the possibilities inherent in this
> facility.
>
It hasn't been documented yet, because the *big* change will be the
ability to prototype totally new renderable objects using subclassing +
PyOpenGL. That stuff isn't ready yet, but it is coming.
What's ready now and here to stay is that Visual's classes are all
first-class citizens in the Python class system (say that three times
fast ;). Anything you expect to do with any other Python class can be
done with these.
-Jonathan
|
