[vtk-developers] python wrappers & external types

[David Gobbi]

On Thu, Jul 1, 2010 at 5:02 PM, Clinton Stimpson <clinton at elemtech.com> wrote:
>
> I've been curious why VTK has its own wrapper generators instead of using
> something like SWIG.

I don't know who made the original decision, and maybe SWIG wasn't
even around back then.  Anyway, I'm glad they didn't choose it.  The
VTK wrappers are very efficient in terms of build-time and very
lightweight in terms of memory.  Also, unlike SWIG, there is no "pure
python" layer on top of each C++ class.  Each VTK/Python class is pure
C++ with a C-Python object interface.

> 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...?

I wrote the QVTKRenderWidget.py in vtk/qt to allow me to put a
vtkRenderWindow inside a QWidget.  I haven't used it in a while, but
I'm guessing that it still works.  No special wrapping was needed,
just VTK/Python and PyQt.

The trick, though, was that I never used any C++ classes that mixed Qt
and VTK in their interfaces. I'm guessing that you do.

   David


>>
>> 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
>