[vtk-developers] Python wrapper change summary

David Gobbi david.gobbi at gmail.com
Fri Aug 6 16:02:37 EDT 2010


Hi Jean-C,

The PyQt licensing issues are definitely something that all PyQt users
should make themselves aware of, but they aren't tainting VTK because
neither SIP are PyQt are being incorporated into VTK.  They are 3rd
party packages that are outside of VTK.

Take, for instance, the situation that used to exist with the Qt
classes in VTK, back when Qt was GPL.  People who didn't want to worry
about GPL simply did not use Qt (or they bought a license).  The same
situation exists now with PyQt.

So, as long as Kitware does not distribute binaries with PyQt/SIP
support, I do not see any problems.  And, of course, people who choose
to use PyQt in their projects must understand that their projects
automatically become GPL.

   David


On Fri, Aug 6, 2010 at 1:52 PM, Jean-Christophe Fillion-Robin
<jchris.fillionr at kitware.com> wrote:
> Hi Folks,
>
> I have few remarks regarding the PyQt and SIP that seems to be used to wrap
> QUISupport/Qt. See
> http://vtk.org/gitweb?p=VTK.git;a=history;f=GUISupport/Qt;h=d9ee2891fdb603124f3d8928f972a5252353e423;hb=HEAD
>
> SIP :
>
> "SIP is licensed under similar terms as Python itself. SIP is also licensed
> under the GPL (both v2 and v3). It is your choice as to which license you
> use. If you choose the GPL then any bindings you create must be distributed
> under the terms of the GPL."
> Source: See
> http://www.riverbankcomputing.co.uk/static/Docs/sip4/introduction.html#license
>
>
> PyQt:
>
> "PyQt, unlike Qt, is not available under the LGPL. If you use the GPL
> version of PyQt then any code you develop with it must be distributed under
> a compatable license."
> Source: http://www.riverbankcomputing.co.uk/software/pyqt/license
>
>
> Both SIP and PyQT are GPL. If I understand properly, we can't use them in
> VTK. Am I misunderstanding something ?
>
> That's why PySide project was created:
>
> "The PySide project provides LGPL-licensed Python bindings for the Qt
> cross-platform application and UI framework. PySide Qt bindings allow both
> free open source and proprietary software development and ultimately aim to
> support all of the platforms as Qt itself."
>
> In the same time, in the context of CTK, I am working with PythonQt and
> PythonQtGenerator. Both are now cmake-ified. I am also working on a set of
> macro similar to vtkWrapPython.
>
> The macro ctkMacroWrapPythonQt will allow to either do a full or a light
> wrapping.
>
> The light wrapping will provide the ability to create and delete object
> (derving from QObject) in python and also call slot and methods added using
> Q_PROPERTY. To achieve such things, a small wrapper allowing to decorates
> the constructor and destructor is created.
>
> The full wrapping will rely on PythonQtGenerator (a modified version of the
> generator used by QtScript) and will allow to have a full wrapping of enums,
> virtual method, non-QObject, ...
>
> Will keep you posted.
>
> Thks
> Jc
>
> On Fri, Aug 6, 2010 at 3:08 PM, Marcus D. Hanwell
> <marcus.hanwell at kitware.com> wrote:
>>
>> On Fri, Aug 6, 2010 at 3:01 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>
>>> Hi All,
>>>
>>> This is a brief summary of new vtk/python features for people to try:
>>>
>>> 1) The wrapping of vtkVariant, vtkArrayRange, vtkArrayCoordinates etc.
>>> has changed.  Each of these types now has its own "type object" which
>>> doubles as the object constructor.  This means that if you do
>>> "help(vtkVariant)" in python, all the methods will be listed.  In the
>>> future, this also means that I will be able to wrap more operator
>>> methods.  For people who want to try out vtkVariant, there is an
>>> example here: http://www.vtk.org/Wiki/VTK/Examples/Python/Variant
>>>
>>> 2) Constants are automatically wrapped, as long as they are defined in
>>> one of the following ways in the headers:
>>>
>>> #define VTK_CELL_SIZE 512
>>> const int VTK_CELL_SIZE = 512;
>>> enum { VTK_CELL_SIZE = 512, ... };
>>>
>>> Some important header files aren't wrapped yet, such as vtkCellType.h,
>>> but they will be soon.  Enums and constant variables that are class
>>> members are also wrapped, so vtkDataObject.POINT_DATA_FIELD can be
>>> used.  Note that the vast majority of these enums have BTX/ETX around
>>> them and are only wrapped because in the git head I am forcing the
>>> wrappers to ignore BTX/ETX in the main "kit" directories.  So the
>>> wrapping of these enums will only become permanent when the BTX/ETX
>>> markers are removed.
>>
>> This is great news, and I am very pleased we can start using the enum
>> values. Can we start using the enum types in our API too, i.e. go from void
>> SetType(int enumValue) to void SetType(enumType enumValue)?
>>>
>>> 3) The vtkDataArray GetTuple() and SetTuple() methods are wrapped.  So
>>> python users don't have to use the SetTuple2(), GetTuple3() methods
>>> anymore.
>>
>> Does this mean we could deprecate some of this API, or is it still very
>> much required for the Tcl and Java wrappers?
>>>
>>> v = vtkIntArray()
>>> v.SetNumberOfComponents(3)
>>> v.InsertNextTuple((1, 2, 3))
>>> or to insert without intermediate conversion to "double":
>>> v.InsertNextTupleValue((1,2,3))
>>> (x,y,z) = v.GetTuple(0)
>>> or use RHS get method:
>>> rval  = [0,0,0]
>>> v.GetTupleValue(1, rval)
>>>
>>> 4) Clinton has added a two-way VTK/Python/SIP bridge and has wrapped
>>> the GUISupport/Qt directory.  I've compiled this but haven't tried it
>>> yet.  A couple tests/examples would be nice (hint hint).
>>>
>>> So, that's it for now.  Enjoy.
>>
>> Sounds great, well worth a few of the length rebuilds required ;-) I will
>> be testing some of this out, and would like to start streamlining the API in
>> some of the classes I work on.
>> Thanks!
>> Marcus
>> --
>> Marcus D. Hanwell, Ph.D.
>> R&D Engineer, Kitware Inc.
>> (518) 881-4937
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>
>>
>
>
>
> --
> Phone: 1-518-836-2174
> Ext: 304
>



More information about the vtk-developers mailing list