Thanks again Matthew for this answer, On 12/13/2013 06:43 PM, Matthew Woehlke wrote: > On 2013-12-13 12:18, Nicolas SAUBAT wrote: >> If I have a C++ class based on both Qt and VTK (like this one : >> http://camitk.imag.fr/apidocumentation/3.2/classcamitk_1_1RendererWidget.html), >> I would be able to expose the VTK part using VTK's Python binder OR Qt >> part using Shiboken, but not both. > *AFAIK* this is correct. At least, I know that I've run into the same > problem and didn't come up with a solution. > >> And then the solution seems to be to still use Shiboken, >> and inject code in the wrapped classes (containing CPython code) in >> order to tell it how to convert the Python object (PyObject) into a >> VTKObject when necessary. Which seems difficult, from the C++ side, >> regarding how VTK handles its VTKObjects. >> Please let me know if I've misunderstood some points ! > No, that sounds about right. > > That said, maybe someone that knows VTK better would have an idea. Have > you asked on the VTK list? Not yet, but I will certainly need in the future !
>> And, by the way, would this problem still occur if we decide not to >> expose to Python the VTK part ? > You can wrap many things in Shiboken. If what you wrap uses Qt classes > (and you are using PySide), then you will be able to wrangle those types > between C++ and Python (which is really a glorified way of saying you > can wrap a method that either takes or returns a Qt type). Where you'll > run into trouble (using Shiboken to do the wrapping) is methods that > take or return VTK object types. (POD's are not a problem in either > case, of course.) Basically, if the API only wraps types that are > themselves wrapped by Shiboken, you'll be fine. (Note however that > you'll lose base class methods if your base class is not shiboken wrapped.) > > You could, conceivably, write your own external shiboken-based Python > bindings for VTK :-). (After all, PySide is separate from / 'on top of' > Qt; no need to be tightly integrated into the VTK repo / build system.) Which seems the best things to do. I will go, step by step, on quite that direction (or failed if it's too hard). I've counted 99 vtk classes included in our code (yeah, less than 100, it's psychological :) ). I will, firstly bind our code hiding VTK from Shiboken, and then expose it class by class. Have you already tried binding VTK with Shiboken on your own ? > Similarly if you use VTK to do the wrapping, VTK types will be okay but > Qt types will be a problem. (Also VTK's binding system has other > limitations, e.g. no STL classes, very poor support for enums...) > >> This way, the CPython extension generated would still be able to run the >> VTK methods trought the C++ library, but forbid to directly handle the >> VTK objects from the Python world (or crashes). > More likely Python just won't "see" methods that deal with VTK objects. Yes, that seems logical. > >> But I don't know if it would be possible to render the 3D of VTK in some >> Qt widget ... > Hmm... I don't think QVTKWidget is a vtkObject(?); you could write your > own wrapping for that and only that with Shiboken that would at least > let you create the widget from Python. Assuming you even need to do that. Yes it is used by Qt to render VTK within a widget. My first goal will be to render the VTK 3D within such a widget, then try as much as I can to wrap the 99 VTK classes with Shiboken. Thank you Matthew for these advices, I will let you know of my wrapping progress of VTK ! -- Nicolas SAUBAT Ingénieur Recherche et Développement Equipe GMCAO - Laboratoire TIMC-IMAG Pavillon Taillefer Allée des Alpes - Domaine de la Merci 38706 La Tronche Tel : (33)04 56 52 00 10 _______________________________________________ PySide mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/pyside
