"The PySide project provides LGPL-licensed Python bindings for the Qt cross-platform application and UI framework. PySide Qt bindings allow both free open source and proprietary software development and ultimately aim to support all of the platforms as Qt itself." Previously, the PyQt bindings were not licensed LGPL. If one wished to make a commercial application, then one previously had to purchase a commercial license for PyQt. Now it is possible to dynamically link to the LGPL-licensed PySide bindings instead. The PySide bindings are API compatible with PyQt.
To read all comments associated with this story, please click here.
Member since:2009-06-30
I've just tried PySide and my (fairly simple) code has failed with an error:
Boost.Python.ArgumentError: Python argument types in
QMainWindow.addDockWidget(MyWindow, DockWidgetArea, QDockWidget)
did not match C++ signature:
addDockWidget(QMainWindow {lvalue}, Qt::DockWidgetArea area, QDockWidget* dockwidget, Qt::Orientation orientation)
addDockWidget(QMainWindow {lvalue}, Qt::DockWidgetArea area, QDockWidget* dockwidget)
I will obviously keep an eye on this project but I don't expect it to be in a usable state earlier than in a year or two.
As for PyQt, I am actually quite happy with it. It's one of the best run opensource projects so I don't think it will suddenly disappear. Still, having LGPL-ed Qt bindings would be great for both Python (it would be fantastic to have robust and portable GUI out of the box on all platforms) and Qt (it would radically lower the entry barrier for its users). It's sad that Nokia hasn't found an agreement with Riverbank.
Member since:2006-07-26
As for PyQt, I am actually quite happy with it. It's one of the best run opensource projects so I don't think it will suddenly disappear. Still, having LGPL-ed Qt bindings would be great for both Python (it would be fantastic to have robust and portable GUI out of the box on all platforms) and Qt (it would radically lower the entry barrier for its users). It's sad that Nokia hasn't found an agreement with Riverbank.
Previously if Riverbank's policy or FAQ or something stated that you were not allowed to use a commercial license for something that was developed using the GPL version. This was a restriction on the commercial license.
Now there is nothing saying that I can't develop my closed source application in house using the GPL PyQT and switch to PySide when both my app and PySide are stable. If I made no distributions during development I don't need to release any source.
BTW, I just finished my first set of Python bindings for an in-house C++ library. It actually wasn't that bad. Pretty easy, but nowhere as big as Qt.
Its good to know there are more generators available but from what I've heard they are all garbage, especially SWIG.
Member since:
2006-07-26
I'm trying to think of a scenario where you would choose riverbank for either GPL or the commercial one and I can't.
If you want to develop an open source GPL project, make all your source GPL and link against the LGPL PySide.
If you want to develop a closed source commercial application, save some money and use LGPL PySide.
This seems like a kick in the crotch to Riverbank.
If it took several man years of effort they should have offered that amount of money for a Riverbank buyout rather than duplicate effort. That is, unless they didn't like the PyQT implementation.