WxWidgets Compared To Other Toolkits

Some general notes:

• wxWidgets not only works for C++, but also has bindings for python, perl, java, lua, eiffel, C# (.NET), basic, ruby and even javascript (see General Information for bindings).
• It is one of the most complete GUI toolkits. There are many utility classes.
• There is a lot of documentation (though a bit fragmented in places).
• Free for personal and commercial use.
• Whenever possible, wxWidgets uses the native platform SDK. This means that a program compiled on Windows will have the look and feel of a Windows program, and when compiled on a Linux machine, it will get the look and feel of a Linux program.

There is also a slashdot thread about cross-platform gui toolkits. Though it is old and, well, it is slashdot :), there are probably some useful insights there.

<script type="text/javascript"> if (window.showTocToggle) { var tocShowText = "show"; var tocHideText = "hide"; showTocToggle(); } </script>

[ edit]

Qt

• Both Qt (http://www.trolltech.com/) and wxWidgets have many non-GUI-related classes, such as date/time, containers, networking and OpenGL functionality. However, if you are developing commercial applications (non-GPL) in Qt and want to use most of these classes (including the OpenGL widget), you have to pay extra for the "enterprise edition" (http://www.trolltech.com/products/qt/licenses/pricing/editions) on top of the normal commercial version of Qt (the "professional edition").
• Qt3 is available under the GPL for open-source applications on Mac and GNU/Linux, and under the QPL for commercial and Windows applications. Qt4 is also available under the GPL for Windows. By contrast, all ports of wxWidgets are distributed under a permissive modified (but explicitly OSI-approved) LGPL, which allows development and distribution of proprietary applications without license costs.
• Qt doesn't have true native ports like wxWidgets does. What we mean by this is that even though Qt draws them quite realistically, Qt draws its own widgets on each platform. It's worth mentioning though that Qt comes with special styles for Mac OS X and Windows XP that use native APIs (Appeareance Manager on Mac OS X, UxTheme on Windows XP) for drawing standard widget primitives (e.g. scrollbars or buttons) exactly like any native application. Event handling, the resulting visual feedback and widget layout are always implemented by Qt.
  • An approach similar to Qt's is achieved with wxUniversal.
  • It should be noted that on KDE and Qtopia platforms, Qt is the native GUI library.
• Qt is used by several large projects like KDE and the Opera browser (on the other hand, wxWidgets is used by projects like the AOL Communicator)
• Qt makes extremely liberal use of virtual functions (QWidget, the base class of all widgets in Qt had 91 at last count), giving it a more OO design than wxWidgets (which uses a more MFC-like approach using macros). What this means is fewer lines of code in general when using Qt, but faster execution speed when using wxWidgets (although the degree to which this occurs depends on whom you ask).
• Qt is used by IBM and Borland Kylix: this should yield more reliability. However, it is rumoured that wxWidgets will be used in the next version of C++BuilderX.
• Qt has a full-featured (commercial and royalty dependent) embeddable GUI (Qt/Embedded) based on GNU/Linux with framebuffer, it gives you a very fast time to market. This means that once you have Linux with /dev/fb you are ready to run examples in minutes, with no additional pains. Qt/Embedded has a small footprint compared with X11.
• There is an IDE for Qt, Qt Designer (though there are also several IDEs for wxWidgets).
• Qt offers reliable commercial support.
• There is nothing to stop somebody writing a Qt-based implementation of wxWidgets, though wxWidgets applications can already be made to appear Qt-native using wxGTK and GTK-Qt.

[ edit]

FLTK

• FLTK website: http://www.fltk.org/
• wxWidgets has a more mature OO design.
• FLTK is more light-weight, whereas wxWidgets is more full-featured (wxWidgets supports networking, printing, etc. while FLTK has limited or no support for these things). See wxWidgets Feature List (http://wxwidgets.org/whychoos.htm) vs. FLTK Feature List (http://www.fltk.org/documentation.php/doc-1.1/intro.html#2_2).
• FLTK actually has more elaborate, different widget types. Just compare what you can do in FLUID to wxDesigner or DialogEdit. I ported a FLTK app to wxWidgets and had a hard time emulating the buttons.
• FLTK's modified LGPL license is more restricting than wxWidgets license, although it does provide exceptions for static linking.

[ edit]

FOX

• FOX website: http://www.fox-toolkit.org/
• FOX is more light-weight, whereas wxWidgets is more full-featured.
• wxWidgets has a more complete API, while FOX focuses mainly on GUI features.
• FOX draws its own widgets on each platform, instead of using the native widgets (like Qt), whereas wxWidgets offers true native ports for all the supported platforms. FOX may be faster because of this, but the provided look-and-feel may not be well integrated into the target platform (e.g. the Windows XP theme is not currently available).
• FOX lacks printing and I18N support.
• Standard Windows dialog boxes are not supported in FOX, but a portable similar feature is available.

[ edit]

Java

• Java is a platform while wxWidgets is a GUI API (and can be used with python, perl, C++, java, lua, eiffel, C#, basic, ruby, etc.) so a comparision of the two may not be completely balanced.
• Java programs are compiled from bytecode at runtime. This means when a user first starts your program, it will take longer to load and the first few moments using the program will be sluggish. (Java compilers such as GCJ are available, but do not support all Java features well/at all).
• On the other hand, wxWidgets is compiled directly to machine code and gains all the speed advantages that go along with that.
• Java bytecode can easily be decompiled. This is not a problem if your application is open source. However, if having users seeing your source code is a problem, then you may wish to consider other options. (Native binaries such as those produced by wxWidgets can also be decompiled, but the process is generally far more difficult than with Java bytecode.)
• Users of Java-based applications must have a JVM installed. In recent years, this has become less of an issue as more computers are being installed with Sun's JVM. However, user's that have an older JVM may suffer from performance/security problems.
• Due to the fact that Java's libraries are slow, some Java libraries are being written in C++ using wxWidgets!
• An example of the above is wx4j, a wxWidgets implementation for Java. wx4j is a wxWidgets binding for Java which allows Java programmers to keep their Java language but still have the speed of a C++ written program.
• In order to be cross-platform, Java generally targets the least common denominator. Features that are only available or relevant on one platform but not others are left out of the Java APIs. Examples include manipulating the Windows taskbar, the Mac OS menu bar, Unix file attributes, etc.
• A corollary of the statement above: in a wxWidgets program, you can always write some platform-specific code where necessary, inside of an ifdef that makes it only compile on that one platform. In Java, there's no equivalent of an ifdef, and you have to jump through hoops to access external APIs. Also, wxWidgets emulates certain features that are not avalible on different platforms (such as MDI and tree controls).
• Java programs invariably consume more memory than equivalent C++ programs.
• While a great idea, "Write once, run anywhere" is still a myth. All JVMs have bugs in them, and it is simply impossible to develop a large Java program on one platform and expect it to work flawlessly on another. Not to say all problems have been eliminated from wxWidgets, but the situation is definitely not worse.
• wxWidgets is in many ways more complete and more intuitive. Compare wxString with java.lang.String. Be sure to compare both the features, and the quality of the documentation.
• Some Java advocates claim that the next version of the JVM will fix many speed problems. However, benchmark tests do not reflect this.
• Benchmarks (using JVM server 1.4.0) show that Java is still significantly slower than C++. Significant enough to warrant the use of C++ over Java.

[ edit]

SDL

• http://www.libsdl.org
• SDL (Simple DirectMedia Layer) is a multimedia C library more suited for when you're writing games and such, and want custom-everything and no convenient general-purpose UI elements. It is made of a lot of C structures starting with SDL_.
• It is possible to combine using wxWidgets and SDL: http://code.technoplaza.net/wx-sdl/
• Under the LGPL version 2.

[ edit]

Allegro

• http://alleg.sourceforge.net
• Much like SDL, Allegro is a cross-platform c library (with quite a bit of assembly used in the backend) for programming games.
• Almost as old as wxWidgets (circa 1993).
• Giftware license (essentially public domain).
• Requires gcc and an assembler to build.
• Development has been stuck in the same version for years, there are a lack of core developers (original developer is no longer on the team), and there are some internal disputes which may lead to a fork.
• Very basic GUI functionality - only supports one window with only bare bones operations supported - you can't move the window, etc.
• "Controls" are sort of supported in allegro also through functions with (many) variable-length arguments, and are owner drawn much like QT (but don't look as good by default). They can be customized via a relatively easy API (and there are a few sub libraries that already have somewhat fair-looking versions).
• Drawing routines are much faster than wx, and there is a opengl layer (allegrogl - http://allegrogl.sourceforge.net/) that makes drawing with opengl even easier than it is to begin with.
• Non-GUI routines (input, etc.) are lower-level and generally faster than wxWidgets' native implementations.
• Can be used with wxWidgets without too much trouble - since allegro has some platform specific functions to get the window handle, you can create a wxWidgets window from the window handle and do what you want from that from that point on. While wxWindows uses a wxApp to handle platform-specific main/WinMain stuff, Allegro requres you put END_OF_MAIN() after your main function - getting the two to work together is somewhat of a task, but not a very large one.

[ edit]

GTK+

• http://www.gtk.org
• GTK+, originally the Gimp toolkit, is a LGPL C-language GUI library for Unix systems.
• It has been ported to Windows, VMS, and other systems (MacOS?) using the same API. However, primary development and focus is for Unix, with multi-platform development mostly as an afterthought.
• Unlike wxWidgets, GTK+ supports C (and there is a C++ wrapper called GTKMM, http://www.gtkmm.org )
• The API is quite well developed, and includes safe casting and other things; but C++ has these built in.
• It's built on top of glib, a general-purpose library (similar in some ways to the C++ STL -- it provides a few data structures, functions to help memory management, etc).
• It looks the same on all platforms, except Windows XP, where it tries (with some success) to get Windows' native look and feel with the Wimp theme, which uses UxTheme. However, it's still very much a Unix library.
• Since wxWidgets uses GTK (or GTK2) on Unix, there seems to be little reason to use GTK over wxWidgets in a C++ program.

[ edit]

Kylix

• Kylix hasn't been much of a success for Borland/Inprise, so it's doubtful how long it will be continued to be supported.
• Kylix is based on Qt, see above :)
• Fewer platforms are supported by Kylix
• The IDE, being based on no less than 3 toolkits, is rather unprofessional.

[ edit]

Lazarus

• Lazarus is a cross-platform and open source RAD IDE, and a library to write GUI software
• Lazarus is compatible with Borland Delphi and the same code can be compiled with both
• It only supports Object Pascal for language
• Working in a similar way to wxWidgets, it has support for many underlying widgetsets: gtk1, gtk2, win32api, qt, carbon and winCEapi
• The underlying Free Pascal Compiler supports most OSes and architectures currently in use
• Currently it supports less platforms then wxWidgets

[ edit]

Ultimate++

• Ultimate++ only supports Windows and Linux, not MacOS
• The comparision on http://upp.sourceforge.net/www$uppweb$vswx$en-us.html isn't really fair. The wxWidgets sample they took is over-engineered to show the reader how to design a wxWidgets application. Their implementation doesn't behave the same, and more importantly, a small example like that doesn't show how the toolkit scales to bigger applications.

[ edit]

Notus

• See: http://sourceforge.net/projects/notus
• wxWidgets actually exists ;)
• notus is likely to make a lot more use of standard library and modern C++ concepts, such as iterators, templates, namespaces, etc (whereas wxWidgets reimplements or works around many of these things in non-standard ways); and it's also likely to follow the design principles of Boost (which you could consider either a good or bad thing), and work well with the rest of the Boost library. Of course, since it doesn't yet exist, whether this is true in practice remains to be seen.

[ edit]

MFC

• MFC is only available for free for Windows
  • A macintosh version was available with Visual C++ Crossplatform Edition (~$800 at last check) but has not been supported by the compiler since version 4.1.
  • There are also UNIX variants such as MainWin, which are extremely expensive, require runtime licenses, and are reported to have problematic support
• While the source for both wxWidgets and MFC is available, EULAs are not a concern with wxWidgets.
• MFC has a smaller executable size than wx (generally irrelevant with a decent compiler).
• MFC has greater range of good quality commercial components.
• Some say event tables (wxWidgets) are 'better' than message maps (MFC).
• wx's class hierarchy is more intuitive, while MFC tends to be more consistent among top-level class names.
• wx provides a far greater abundance of convenience classes, while MFC provides more windows-specific classes.
• .NET isn't an issue - MFC won't be ported to .NET. On the other hand, wx already has .NET wrappers in alpha stage!
• MFC has a broader range of components available, especially data-bound controls.
• Some things are easier with wxWidgets, such as certain types of windows (always on top, etc.), while other things are easier with MFC, such as detachable toolbars.
• Probably the strongest point to use MFC is MSVC, the IDE, itself.
• For info on class names and other points, see WxWidgets For MFC Programmers

[ edit]

Mozilla Framework

• See: http://www.mozilla.org/why/framework.html
• JavaScript, XUL and C++ are all needed to program in Mozilla; wxWidgets only needs C++.
• Programming Mozilla in C++ (XPCOM) is very difficult; C++ in wxWidgets is easier.

[ edit]

Tk

• AKA: Tcl/Tk, Perl/Tk, Python/Tkinter
• See: http://wiki.tcl.tk/tk, http://wiki.python.org/moin/TkInter
• Old api, but stuck to basic functionalities. Many extensions provide new widgets: the well-known BWidgets extension (for Tcl/Tk) provides megawidgets coded in pure-Tcl (scripted only).
• Does not have GridView ~ ListViews, but a simple list
• ComboBox is kind of buttons
• Double click is default command but if you want "one-click" or other event, there is support but you can't find it easily.
• Python claims to use this widget class by default but some distros (like Pardus) dont include by default.
• there is a StringVar, IntegerVar, DoubleVar classes to get a value from a widget, it is confusing.
• It has a native look-and-feel on MacOSX (since a long time) and Windows (XP native style with the Tile extension, elsewhere it has Win9x look-n-feel)
• It does not look well under X11. In fact, it looks a bit like Motif :-( but watch the Tile extension, which aims to revitalize Tk on X11.
• Tk is an extension of the Tool Command Language, which is a cross-platform, powerful scripting language. But I admit, the learning curve for Tcl may be high, since it is quite a different language than C/C++.
• You can wrap complete Tcl/Tk apps into one binary file - a standalone Starpack, or a Starkit that is ran with a small footprint intepreter called Tclkit. Deployment is as easy as can be.
• Feel free to add notes here...

[ edit]

VCF

• See: http://vcf-online.org/
• Clean OO design
• Mature on Windows, some support for MacOSX and Linux
• BSD licensing

[ edit]

WideStudio

• See: http://www.widestudio.org/
•  ??? Anyone used this?

[ edit]

Why You Shouldn't Use wxWidgets

• Lack of commercial GUI components for making nice GUI grids, charts, etc. Look at wxCode though.
• No support for themes (apart from using the themes of the underlying toolkit) unless you use wxUniversal or wxSkin
• wxX11 is sub-par compared to other toolkits and unstable. You should use the wxGTK port instead, which builds upon GTK instead of directly onto X11. wxX11 is mostly intended for embedded devices that don't have GTK.
• wxWidgets tries to support a very expansive feature set, and as a result, some lesser-used components of the toolkit are not as stable/reliable as commonly used components are. As with any open source toolkit, thorough testing is the best solution here.