Moving to PyQt

January 19th, 2009 at 5:40 pm

The 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.

http://eli.thegreenplace.net/wp-content/uploads/hline.jpg
[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:

  1. PySide – Nokia-sponsored LGPL bindings to Qt
  2. Tetris implemented in PyQt
  3. matplotlib with PyQt GUIs
  4. Book review: “Rapid GUI Programming with Python and Qt” by Mark Summerfield
  5. New-style signal-slot connection mechanism in PyQt

10 Responses to “Moving to PyQt”

  1. JohnNo Gravatar Says:

    I think it’s even bigger than you suspect, Eli.

    My guess is that PyQt will become the default GUI choice for Python in short order (as soon as the license change hits).

    But it’s not just the Python community. Perl and Ruby developers (and others) also have dealt with the same tough choices re. GUI toolkits, and they’ll all go Qt as well.

    And I’ll throw even one more log onto the fire: what does this mean for Gnome? Ubuntu makes heavy use of Python, and Ubuntu is quite popular right now. I’ve been a Gnome user for a long time now (haven’t considered or looked at KDE in years), but I’ll be checking out Kubuntu soon — certainly after they ship with Qt 4.5.

  2. elibenNo Gravatar Says:

    @John,

    I agree. And re Gnome, it’s indeed a bigger story. KDE and Gnome are neck to neck for years, and this will be a huge boost to KDE, no doubt. I have no experience with GTK+, but it’s extremely hard for me to believe that it can be as robust as Qt, being object oriented C.

  3. danNo Gravatar Says:

    I know Qt is moving to LGPL but are you sure PyQt is? It’s developed by Riverbank, not Trolltech/Nokia.

  4. elibenNo Gravatar Says:

    It’s very hard to believe that won’t move to LGPL eventually. If they won’t, someone else will make an alternative Qt binding in Python and make it LGPL.

  5. Rene DudfieldNo Gravatar Says:

    Qt is a massive API. Creating a new binding is no easy task. Think many years work, by dedicated knowledgeable people.

    Maybe nokia will pay for it to be released LGPL.

  6. MatthieuNo Gravatar Says:

    I have to say, although I’m a huge Qt fan (C++), I really prefer wxPython over PyQt. The API seems more native for wx than PyQt, although it’s the opposite in C++.
    My other rant is toward the signal/slot mecanism, which does not seem to be as reliable as the C++ version (but I’d like to be proven wrong). I’ve made a simple GUI app where computation is done in a worker thread. I couldn’t get the worker thread signal the GUI thread in a multithreaded way, or more precisely, I couldn’t explicitelly change the connection way (direct or event).
    But with a wrapper that is more Pythonistic and a better signal/slot handling, I would also go for Qt.

  7. devskiNo Gravatar Says:

    i find that students seem to understand wxpy better pyqt, especially for new python programmers. one common problem is setters/getters. it looks so are alien for those who never have c++/java background. the use of properties seems more natural to them.

  8. SamNo Gravatar Says:

    I find the author was very much excited (I like such enthusiasts) about PyQt but these days I find more dedicated Wx Python developers.

    Further, today’s Jun 30th (Almost 5 months from the initial post), still PyQt is not LGPL.

    I was searching for the comparison between WxPy and PyQt and met this article. I find it very good and balanced but for the license. (Back to square 1 on why should we adopt it?)

    Cheers,
    Sam

  9. elibenNo Gravatar Says:

    @Sam,

    Choosing a platform has so many partly-orthogonal implications that it’s not a black and white business. Personally, for the kind of coding I do now, I’m happy with PyQt despite its licensing. After spending months with it, I’m even more convinced that it’s a better platform than wx. But maybe it’s just me.

  10. PythonSloveniaNo Gravatar Says:

    Until recently I’ve also been using wx for my Python GUI needs and after I stumbled upon this article of yours I’ve also started to take a look at PyQt. And I must say I’m extremely impressed by it so far. It appears to be much reacher and much more consistent in its API. The license GPL doesn’t bother me at all. For the last couple of weeks any project I start now uses PyQt for GUI. I find it even that PyQt has better native look on different desktops, especially on Linux. The only bigger drawback I see for now is the amount of documentation I need to red to get myself up to speed by all what Qt has to offer. But as I said great API it has helps a lot here as I can guess many stuff.