Just a friendly reminder that much of the following reflects my personal experiences and consists of my personal opinions, for better or worse. No offense is intended to either group; I respect the accomplishments and offerings of both communities a great deal.
Both Qt and wxWidgets are multiplatform GUI toolkits that are written in C++ and have bindings available for many other languages. Qt and wxWidgets are available for free as open source software and have multiple licensing models for closed source users. Qt previously suffered from licensing issues regarding whether an application were free or commercial, but Nokia has changed this. Both are available on Linux, Mac, Windows, and BSD. Started almost two decades ago now, the two toolkits are very mature and widely used.
Feature wise, both toolkits are very capable to the point of being equal in terms of providing windows, buttons, input boxes, trees, sliders, etc, as well as ways to create custom controls. If the needs of an application do not extend much beyond simple GUI needs, either toolkit would suffice. Similarly, both provide ways of presenting multimedia, including 3D OpenGL windows, and language translations.
The distribution of programs using Qt and wxWidgets is very similar. On some platforms the libraries should be included along with the program through an installer or static compilation (Windows and Mac). This can ease release management but add to packaging headaches. Other platforms package the libraries and users will need to install them from their vendor (Linux, most BSDs). This situation presents the opposite scenario, where packaging may be simpler but there is no control over the fine details of the underlying toolkit.
The rest of this document will focus on the differences between Qt and wxWidgets.
Qt is maintained by Nokia, who purchased Trolltech. Qt has its roots in commercial software and a history of corporate ownership and stewadship. wxWidgets has been developed as an open source project from its beginning by Julian Smart.
Among X users such as the Linux community there are generally two camps: KDE users who favor Qt (due to KDE being built with Qt) and GNOME/GTK users who favor wxWidgets (due to wxWidgets being implemented using GTK+ on those platforms). Thanks to efforts by the developers of KDE and GNOME, it is now rare to encounter users who cannot use or refuse to use applications not written in their preferreed toolkit. Applications on a properly configured desktop system will use desktop themes to maintain a consistent appearance.
The choice between communities could be, for some, significant. Outside of the realm of KDE development on Linux, Qt has a large base of professional developers. These commercial developers participate in assisting others to varying degrees. The wxWidgets community appears to be the more accessible of the two, with a large number of not-for-profit development of, e.g., scientific software and a generally more actively participating community.
Since version 2.4, I believe, wxWidgets has utilized a generic build generation system called bakefiles. Typically, unless a developer is working on wxwidgets itself, neither users nor developers will need to create, edit, or interact with bakefiles (that is, unless they wish to use bakefiles in their own application). Bakefiles can be used to generate a variety of build system files, but most usually Visual Studio and GNU autotools are targeted.
Qt uses qmake, a multiplatform build tool. Its operation is basically similar to the described bakefiles above. However, developers building their own version of Qt will have much more interaction with qmake than those building wxWidgets will interact with bakefiles. Also, qmake is a common choice for Qt application developers whereas wxWidgets application developers preferences vary (GNU autotools, Visual Studio, nmake, scons).
Qt utilizes native widgets on Windows and Mac. On systems using X Qt draws its own widgets through Xlib and is now commonly used as a ‘native’ toolkit for those platforms. wxWidgets similarly uses native widgets on Windows and Mac. However, on X systems GTK serves as the native toolkit. Operation of both toolkits on Windows and Linux is stable and mature.
On Mac OS X, Qt has typically provided more stability and maturity than wxWidgets. There are two current wxWidgets implementations on Mac: the stable wxMac on Carbon and the new wxOSX on Cocoa. The unfortunate consequence of the stable branch relying on Carbon means that there is currently no stable 64 bit vesion of wxWidgets on Mac. To achieve a 64 bit version, the wxOSX port must be completed, which is scheduled to ship with version 3.0.
While the current binary distribution of Qt for Mac OS X is 32 bit, 64 bit support on Mac is stable. Application developers will need to download the source distribution and compile a 64 bit version.
Even before Trolltech was acquired by Nokia, Qt was being ported to mobile phones. Now, with Nokia’s involvement, Qt is mature and stable on the Symbian and Maemo/Meego phone platforms. A mature port of wxWidgets exists for Windows Mobile. Neither toolkit has been advertised as useful for iPhone, Android, or Blackberry development. Presumably, this is due to a lack of vendor and language allowances (Objective-C / XCode requirements, Java reliance).
Both Qt and wxWidgets have an abundance of helpful utilities to assist developers creating applications. However, this is probably (aside from technical implementation details) where the two toolkits are the most different.
Qt is distributed with a set of utilities created by the Qt developers, including a GUI builder and language translation utility. In stark contrast, wxWidgets does not include any utilities in its distribution, though most of the community is using the open source PoEdit to perform translations. Even worse, while there are several GUI builders available only the commercial offerings typically are stable, complete, and run on Mac OS X. Additionally, neither the open source or commercial GUI builders use the same file format (excepting the use of the XML GUI specification XRC). This can lead to open source developers releasing difficult or impossible to change source except for those who pay for the commercial software. Perhaps worst of all, commercial GUI builders for wxWidgets are developed by core wxWidgets contributors.
It is doubtful given the situation described above wxWidgets will ever gain a free, open source, standard, stable, complete GUI builder. While one school of thought may be that it is the community’s responsibility to do so, the leadership in the community have found profit in their own solution. Other attempts have resulted in fragmentation and frustration among users. Surely in this day and age of application development such a tool can be considered a requirement for development at all levels. It is my opinion that this situation has significantly affected the use and experience of wxWidgets and should be a matter of extreme embarrassment for that community.
I will probably organically grow, rewrite, and reorganize this article as different things come to me.