[vtk-developers] python wrappers & external types

[Clinton Stimpson]

I've been curious why VTK has its own wrapper generators instead of using 
something like SWIG.

On Thursday, July 01, 2010 04:45:46 pm David Gobbi wrote:
> I've written a few demos and one large application with VTK/Python and
> PyQt, so items like this are definitely on my mind as I'm working on
> the VTK wrappers.

Did you make a general solution to VTK & Qt interoperability in python?
Or did you create C++ classes that were wrappable to deal with the VTK + Qt in 
places where you needed it?
Or some other way...?

> 
> What I'm thinking of doing, now that the wrappers can deal with
> "non-vtkObject" objects, is to eventually treat all externals as
> opaque types.  So let me know if the following would work for you.
> 
> Tomorrow I'm adding my vtkWrapHierarchy support to VTK, which allows
> the VTK wrappers to do the following:
> 1) find out if any type they encounter is external to the kit
> 2) find the base class of any type in the kit
> 3) find the header file for any class in the kit (i.e. for helper classes)
> 
> For my first commit, this information will only be used in a very
> crude manner, i.e. to make sure the wrappers don't wrap methods with a
> "vtkSomething *" parameter unless "vtkSomething" is derived from
> vtkObjectBase.  This will allow the VTK BTX/ETX markers to be
> eliminated for such methods.
> 
> In the future, though, external objects could be detected and wrapped
> as opaque objects.  They would dealt with using reference semantics
> (rather than value semantics) but I don't think that will be a
> problem.  As far as the wrappers are concerned, there will just be a
> pointer to some unknown object being passed back and forth.  The only
> thing that we have to worry about is getting a reference to a
> temporary that disappears before the reference does, so it might be
> necessary to do some fancy stuff with python weakrefs.  I haven't
> thought that far ahead, though.
> 
> If I ever get around to doing it myself, it would be a while before I
> could start on it.  But if you are inclined, I can point you to the
> interesting places in the code.

I'd like you to point me to the interesting places in the code.

Clint