wxPython vs. pyQt

[Hans-Peter Jansen]

eholbroo at kaustinr.r.com wrote:

> I've narrowed down my toolkit selection for my project to wxPython and
> pyQt, and now i'd like to hear any opinions, war stories, peeves, etc,
> about them, particularly from anyone who's used _both_toolkits_. I'm
> only mildly interested in the IDEs and UI designers for each, as i
> want to do as much as i can in just Xemacs and xterm. Feel free to
> rant, rave, pontificate, whatever.
 
I used both toolkits in projects under linux (mostly for inhouse database
applications and the like). First experiences with tkinter and it's look
within linux brought me to the decision to try others. Although not
necessary that time, being able to use it under windows was appealing.
Because of the Qt license, I decided to start with wx, but several issues
with it turned my head around soon thereafter.

Here is what I still remember:
 - inconsistent api (for historical and conceptual reasons)
 - solutions to some problems weren't always obvious
 - somewhat opaque documentation
 - painfully slow start of wx applications
 - gui layering makes it hard to locate a problem domain inside the tk
 - widgets behave different on different architectures/base libs
 - patched swig needed for full build/own extensions
 - tools (gui builder) weren't appealing
 - printing a single fax page image resulted in a ~50MB PS job (because it
   wasn't possible to prevent the conversation to a 24 bit image)
 - spurious gtk error messages

While in PyQt world, I found these advantages:
 + conceptually vastly superior
 + powerful api/widgets/features
 + fast as hell due to the efficient binding of a quite efficient lib
 + cool tools, that are unicode/translation aware
 + very efficient programming environment/unbeatable productivity

While this sounds like the average sales talk, I will try to backup these
claims a bit:
Phil Thompson does a great job with sip: since V.4, it's able to wrap c++
libs directly without any additional "trampoline" modules, most other
wrappers (includding sip 3) produces. It creates a very thin layer, which
results in a tight and efficient binding. Besides all the necessary
essential work there, it also realizes lazy binding in order to speed up
loading big libs like qt once more. Qt itself is a good example of a
mostly well thought out toolkit including a quite consistent api, usable
documentation and powerful tools (designer, assistant, linguist), which
PyQt fully deploys into the wonderful world of our favorite programming
language.

Accompanied by eric, itself a great example on how far you can go with
PyQt and limited human resources (unfortunately), it is big fun to get
some real work done. The power of eric is largely based on qscintilla,
Phil's Qt port of the scintilla editor component besides PyQt. For the
scientists out there, there's also a cool extension lib available: PyQwt.

On the down side let me note:
 - due to the tight coupling of Qt, PyQt inherits one of Qt's few down
   sides, which boils down to: garbage in -> (probably) crash, but well,
   we use a real operating system for a reason, don't we ;-)
 - to get most from the documentation, one gets to a c++ -> python
   converter over time (trains the eye to skip the right portions)..

Conclusion: PyQt is the most underrated python gui toolkit out there, but
beware: once you get infected, your brain will tend to refuse to work
with more long winded toolkits. It allowed me to do things in hours,
which literally took weeks with tkinter, while still running quicker,
looking and feeling better, providing more features and a noticable
higher user satisfaction: IOW, much more fun.

Well-I'm-biased-ly-y'rs,
Pete