Eli Bendersky's website » Moving to PyQt
Moving to PyQt
January 19th, 2009 at 5:40 pmThe Qt announcement
This week Nokia [1] announced that beginning with version 4.5, Qt will be also licensed with the LGPL. This is a very important announcement that has been making waves in the open-source community for a few days now.
To understand why it’s so important, one has to have some experience with Qt. Qt began as a GUI library for C++, but in time turned into a whole programming framework with classes for networking, threads, databases, binary data access, streams, and much more, all cross-platform. Qt has been commercial and widely used for many years, and grew into a very high-quality library. Some notable programs developed fully or partly with Qt: Google Earth, Mathematica, VLC Player, KDE, KOffice, Skype and lots of applications on embedded devices.
I’ve had the pleasure to use Qt (in C++) before, and have very fond memories from it. Simply searching this blog for Qt brings up lots of very positive reviews from a few years ago. I think I can safely say Qt is the best designed framework/API I’ve ever used in C++ and probably in any language. It has a very talented team behind it, and through years of massive use and customer feedback grew into a true gem. Qt is fun to write in, it’s cross-platform, fun, extremely well documented, simple to use and powerful.
Python, wxPython and PyQt
When I got started with Python a few months ago, I considered the choice of a GUI library, which is important for my work. After a brief consideration, I’ve picked wxPython because it seemed to have a larger user base, and because of Qt’s lack of truly free license (only commercial and GPL).
I’ve enjoyed working with wxPython – it’s a very good binding to wxWidgets, and the team supporting it is great and dedicated. Really, thanks for all the hard work, guys!
However, now with the Qt announcement, I couldn’t help but look at PyQt – the Python binding to Qt. I expect this announcement to eventually turn PyQt to LGPL as well [2] and bring a much larger user base to it, because Qt is a truly wonderful library.
wxPython, it’s not you, it’s me! It has been a fun few months using you, but I’m just madly enamored with Qt, and its Python binding is also very good, so I’m going to switch. Luckily, it’s not yet too late to switch, as I haven’t written too much wxPython code yet.
PyQt, initial impressions
PyQt seems like a robust wrapper around Qt itself. It’s quick, stable and well documented and supported. In the past few days, I’ve reimplemented some basic GUI apps in PyQt to get a feel for it, and managed to integrate Matplotlib into it as well [3]. I’ve also used Pyinstaller to package PyQt apps – the executables are about 9 MB in size and load quickly enough, which is reassuring. It’s great to see a lot of classes from Qt reflected to Python:
- QtSvg – SVG decoding and rendering
- QtScript – a JavaScript interpreter
- QImage
- QNetwork
- Robust and optimized classes for handling XML
- QtWebKit
There are also lots of smaller utility classes that can be very useful:
- QSettings
- QTemporaryFile
- QHelpEngine
- QSyntaxHighlighter
- QFileSystemWatcher
- QCompleter
Some annoyances:
- The need for explicit conversions from QString to Python’s strings, from time to time
- The need to specify C++ signatures in some built-in signals when connecting them to slots
Comparison with wxPython
This comparison is by no means complete, and is highly subjective. Moreover, it’s based on a very limited experience with PyQt (and not much more with wxPython), so take it with a slab of salt.
wxPython’s wins
- wx’s widgets are more native than Qt’s, especially on some platforms. I think this is more a matter of purity than a real impact. For me, as I write 99% for Windows, it isn’t important at all.
- PyCrust – an integrated terminal and shell. Qt has a couple in the works, none as complete and robust
- The wx DLLs are smaller than Qts, so the memory footprint is smaller for wx apps [4]. Also the executables "compiled" with Pyinstaller/py2exe are smaller.
- Much more examples and demos
- Currently (emphasis important!) the wxPython user community is larger
PyQt’s wins
- Qt’s API is better – more orthogonal and logical. It’s simpler to intuitively find a needed method or class than in wxWidgets.
- Qt itself has a far larger user base than wxWidgets, lots of it commercial. This definitely reflects on the library’s overall quality, performance and stability. And since PyQt is rather a thin and efficient layer around Qt, these qualities are important for PyQt applications too.
- The graphic drawing and canvas capabilities of Qt are more advanced
- As I’ve mentioned before, Qt has a huge store of useful classes for various non-GUI needs. All these classes fit very well together and play nicely with the GUI parts.
- I firmly believe the user base for Qt will grow because of the LGPL license, and this will eventually reflect on the user base of PyQt as well. I find very few reasons for a new developer looking for a Python GUI library not to pick PyQt now.
- If I’ll ever need to write C++ GUIs again, I’ll definitely go for Qt [5], and it will be easy to share knowledge between Python and C++, because the underlying Qt framework is the same.
Conclusion
I applaud Nokia for their decision, and both expect and hope that it will eventually prove beneficial for them. For the open-source community and programmers in general, this is a huge boon!
I plan to switch my GUI-related Python coding to PyQt, effective immediately. Although wxPython is a good binding, I like PyQt more, mainly because I like Qt itself much more.
[1] Nokia has acquired Trolltech, the company that develops and maintains Qt, about a year ago.
[2] The economics here are simple. If Riverbank won’t switch PyQt to LGPL, someone else will write a competing binding. Riverbank’s best shot is release as LGPL and make money from support and consulting, building on the increasing user base.
[3] Code snippets will come at a later date
[4] Although PyQt doesn’t load slower. Perhaps even a bit faster.
[5] While this is a rare need for me, it arises from time to time. When I had to write a Windows GUI in C++ for performance reasons a couple of years ago, I used the Windows API and not Qt because of its licensing. Related posts:
