> > > 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. >> >> Compared to PyQt, our binding creates bigger binaries, but it may be >> better with hand written rules... And we could discuss with SWIG guys on >> that point. >> > > "may be better" is a bad argument. Historically PySide used Boost, it > generated a lot of garbage too, and that's why Shiboken was born (correct > me if I wrong). The only problem with Shiboken maintainability is that it > is written in C++ and most PySide users with primarily Python background. > SWIG doesn't tackle this core flaw at all and may become an additional > hurdle that will bury the project even more. > > The good solution (tm) is not to rewrite Shiboken from scratch, but find a > way to gradually move the logic out of it into Python. >
I don't want to hurt anybody. I just want to find a way to see a Qt5 binding soon. If it's with Shiboken it's fine to me... but I can't help on that. I'm personally not interested to create yet another binding tool. I just want Qt5 available in python. Swig has become one of the most popular binding tool. It's really accessible for all people to create rules. This could help to extend the community around PySide. For example, I could help and some people around me too. IMHO, it's always the same problem in the open source world... the difficulty for communities to work together. There is always a lot of open source software to do same thing, but rarely a good one inside this profusion. Are people from Shiboken not interested to work on Swig? Why? I see the reason to eliminate boost python. Is there a reason to eliminate Swig? > Anyway SIP is GPL or commercial... so this is not an option. >> > > SWIG is GPL too. http://en.wikipedia.org/wiki/SWIG > Yes the SWIG core but... "The intention of the SWIG license is to ensure the SWIG source code (the code that is compiled into the SWIG executable) remains as free software by using the GPL license <http://www.gnu.org/copyleft/gpl.html> on the SWIG source code. SWIG also generates code and the intention of the SWIG license is also to enable distribution of the generated code under license terms of the user's choice/requirements. Users are responsible for ensuring that they meet any license requirements for all code fed into SWIG that is subsequently used in the generated output. *Note that portions of the SWIG library are used in the generated code and this library code distributed with SWIG is licensed under a very permissive license that allows further distribution without any obligations.*" it would be pity to throw away all the hard work of developers on shiboken. > No, it could be a great opportunity to bring this expertise to SWIG! And make the world wonderful. ;) But I understand the history of SWIG with binaries sizes. I don't have the project with me, but I will check that and send you that information in detail.
_______________________________________________ PySide mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/pyside
