[PySide] PySide - Qt5 - Swig

[Zak]

Hello Fabien,

I am curious, what is the project you are working on that uses C++ 
widgets, SWIG, and PySide?

I personally like the idea of using SWIG to build Qt bindings. SWIG is 
the only tool I have ever used to interface C++ and Python, and it 
seemed fine. All of the alternatives to SWIG seemed worse.

For those who don't know, PyQt uses SIP. SIP is similar to SWIG in many 
ways.

Here is to hoping that PySide will thrive and grow,

Zak F.

On 1/12/13 5:52 PM, Fabien Castan wrote:
> *Hi,
>
> The email « PySide is dead ? » has given rise to an interesting 
> discussion about the evolution of PySide. The conclusion is that there 
> is currently really limited contribution on the project, and shiboken 
> seems to be a really big and hard task to maintain.
>
> The idea to rewrite shiboken with a new solution (like LLVM, etc.) is 
> great in theory but represents a really huge amount of work and 
> doesn't seem appropriate to the situation. So we would like to propose 
> another solution for the evolution of PySide.
> Instead of rewriting a new binding tool, we could use an existing one 
> and only do the job of PySide which is to give a python binding to Qt. 
> So only implement the binding rules.*
> *
> We started some work with SWIG which is a really wide used binding 
> tool.This could help to get a wider set of developers on the project. 
> All guys from SWIG already work on the binding tool and all users of 
> PySide which know SWIG (or are interested to learn SWIG) could easily 
> contribute.
>
> To explain our history...
>
>   * We have a big C++/Qt application with a Swig binding of the core.
>   * We wanted to create new UI tools in python which need to use some
>     of our C++ widgets. So we need a binding of our C++ widgets. As
>     our core binding is written in Swig (and we are happy with that)
>     we need to bind our widgets with the same binding tool for
>     compatibility.
>   * So we created a binding of Qt in Swig. As the rules were already
>     written in PySide, we write a little tool to convert PySide rules
>     (typesystem xml files) to swig files + some manually written files
>     for additional things.
>   * We worked with this binding during one year, but there were a lot
>     of missing rules to get a full pythonic Qt binding. Tools like
>     pyuic and pyrcc are also missing. Qt is really big, so there is a
>     lot of things to do to adjust the API to another language. But the
>     fact that Swig allows to put some code using the target language
>     is really useful for that.
>   * The conclusion was that it’s too big to be done and maintain by
>     our team.
>   * We switch to PySide and do some annoying work to bind our C++
>     widgets with shiboken and write some conversion rules... because
>     some function arguments of the widget (binded with shiboken) are
>     core object binded with Swig...
>
>
> Now it works with that, even if we have limited the binded widgets to 
> the minimum.
>
> But now we would like to switch to Qt5... ;)
> It seems that it wont be done by the PySide team. So we think that a 
> solution is to do a Qt5 binding in Swig.
>
> Our experience proves the feasibility to bind Qt with Swig. Maybe some 
> really specific things need fixes in Swig... But the main complexity 
> of our project was the mix of 2 solutions: typesystems and custom Swig 
> rules. So we would like to write it directly with Swig rules.
>
> Our experience also proves, that it’s only possible to do this as an 
> open source project with a lot of people involved. But I’m sure, there 
> is a such community around Qt that are interested in an LGPL python 
> binding that supports all the outstanding work provided by Qt5 and in 
> particular QtQuick2!
>
> Are PySide developers interested to explore this approach?
> Are other people interested to explore this approach with us?
>
> Regards,
> Fabien
>
> PS: We also recommend the use of github for the ease of forking, 
> submitting « pull request », reviewing, having a bug tracker linked 
> with the code, and for the responsiveness (gitorious is quite 
> unusable...) and the fact that its use is widespread. This could help 
> to boost the project.
> In all case, having duplicated versions of the project between github 
> and gitorious is the worst solution. It has created a lot of confusion 
> for us.*
> *
> *
>
>
> _______________________________________________
> PySide mailing list
> PySide at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/pyside