It would be nice if there were such a thing on http://qt-project.org/wiki/PySide_Binaries_MacOSX The Windows page has had one for a while. Surely someone has built a binary -- yes?
On Dec 14, 2013, at 6:00 AM, [email protected] wrote: > Send PySide mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.qt-project.org/mailman/listinfo/pyside > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of PySide digest..." > Today's Topics: > > 1. Re: Binding C++/VTK code using Shiboken (Nicolas SAUBAT) > 2. Re: Binding C++/VTK code using Shiboken (Matthew Woehlke) > > From: Nicolas SAUBAT <[email protected]> > Subject: Re: [PySide] Binding C++/VTK code using Shiboken > Date: December 13, 2013 12:18:44 PM EST > To: [email protected] > > > Hi Matthew, > > Thanks a lot for your answer ! > > So if I understand correctly (as I'm still a beginner in the Python binding > world / Shiboken). > 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 (or I send $$ to VTK to convert them to Shiboken > ;-) 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 ! > > And, by the way, would this problem still occur if we decide not to expose to > Python the VTK part ? > I mean, we still consider C++ classes based on both Qt and VTK, but only > describe in the typesystem.xml files for Shiboken, the C++ and Qt objects we > want to expose (thus no rules for VTK objects). > 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). > But I don't know if it would be possible to render the 3D of VTK in some Qt > widget ... > > Feel free to react, as I said I'm not an expert, any advice is welcome > (except sending too much $$ to kitware ;-) ) > > Thanks, > Nicolas. > > > On 12/12/2013 06:07 PM, Matthew Woehlke wrote: >> On 2013-12-12 11:09, Nicolas SAUBAT wrote: >>> I'm trying to bind to Python a C++ framework, called CamiTK >>> (http://camitk.imag.fr) which is based on Qt and VTK (http://www.vtk.org/). >>> For binding Qt C++ classes, no problem, we can tell Shiboken how to use >>> Qt in Python, thanks to the provided typesystem.xml files. >>> But I was wondering, how we can do the same stuff using VTK ? >> Well. That's a good question. >> >> If you just want to generate bindings for VTK-based objects, VTK has its >> own wrapping system that will allow you to do that. (IME it's rather >> limited compared to Shiboken; no support for enums, STL containers, >> etc.) However, getting the two to talk to each other is likely to be an >> issue. >> >> What you would ultimately need to do, I think, is to be able to teach >> Shiboken how to get a vtkObject* from a PyObject. As far as the Shiboken >> architecture, I think you should be able to write custom converters for >> this. >> >> The problem comes with how VTK implements its conversions, which depends >> on having a pointer to the call arguments, which is not available in >> Shiboken. As such, I'm not sure that (at the C++ level) it is possible >> to get the vtkObject* from *just* a PyObject. >> >> TBH, I have the same problem and haven't solved it, except that I >> decided the best thing to do would be to rewrite VTK's wrapping to just >> use Shiboken and be done with it ;-). If you find a solution, please let >> me know. (If you can throw $$ at making VTK use Shiboken, please also >> let me know ;-).) >> >> Note that it's probably impossible to wrap a VTK-derived object with >> Shiboken in any useful way. >> > > -- > 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 > > > > > > From: Matthew Woehlke <[email protected]> > Subject: Re: [PySide] Binding C++/VTK code using Shiboken > Date: December 13, 2013 12:43:13 PM EST > To: [email protected] > > > 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? > >> 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.) > > 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. > >> 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. > > -- > Matthew > > > > > _______________________________________________ > PySide mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/pyside
_______________________________________________ PySide mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/pyside
