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