[EMAIL PROTECTED] 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 -- http://mail.python.org/mailman/listinfo/python-list
