[vtk-developers] Python wrapper change summary

Fri Aug 6 16:51:19 EDT 2010

Clinton has already started thinking about PySide, but I doubt that
there are any plans made yet.

  David

On Fri, Aug 6, 2010 at 2:22 PM, Jean-Christophe Fillion-Robin
<jchris.fillionr at kitware.com> wrote:
> Yes it makes sens and since there are the options: VTK_WRAP_PYTHON and
> VTK_WRAP_PYTHON_SIP the GPL contaminant code is self-contained.
>
> I guess in the future we could think of VTK_WRAP_PYTHONQT and/or
> VTK_WRAP_PYSIDE  ... that way we could accommodate all users.
>
> Jc
>
> On Fri, Aug 6, 2010 at 4:02 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>
>> 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
>> >
>
>
>
> --
> Phone: 1-518-836-2174
> Ext: 304
>