I have decided that I need to teach myself Qt in my copious free time. I had long resisted learning Qt for a few reasons, topping the list being Qt's heavyweight (i.e., non-native) widgets and the lack of a good fully integrated IDE. However, at some point Qt began painting with native widgets when possible on many platforms (KDE was always native; I believe GTK+, Windows, and OS X now also paint with native OS widgets), and recent releases of the Qt Creator IDE work acceptably well in integrating GUI design and code writing, automatically linking the two as with Delphi, Visual Studio, Netbeans, Lazarus, and SharpDevelop.

My enthusiasm for Qt had also been tempered by its licensing. In the past, it was available under a libre and gratis GPL or an expensive commercial license, and anything made with the GPL version was required to be published under a GPL-compatible license. In early 2009, Qt converted their GPL offering to LGPL, which lets you link to Qt libraries even in proprietary apps. So licensing is no longer an issue.

Another thing that's kept me from getting really excited about Qt is that its native language binding is C++. C++ (like C before it) is a great “medium level” system programming language. But for high level development it's just a pain. There are a ton of language bindings for Qt, however none of these are supported by Qt Creator–which brings us back to one of my primary objections. I don't know if GUI building will ever be integrated with code writing for anything but C++, so for the present it means I need to make peace with C++ if I plan to use Qt.

It could be worse. It could be straight C.

Some people get bothered by the fact that Qt isn't “pure” C++: source files for Qt projects use some macros and custom syntax foo that requires them to be passed through a meta-object compiler (moc) to make compiler-ready code. I'm not so bothered by this as long as the modifications are regular and few.

So, as far as major objections go, the only one that's really relevant is the language issue.

There are a lot of different multi-platform development environments. Why Qt? Why now? First, let's consider some of the other options. I have a strong preference for FOSS solutions (there are lots of reasons for liking FOSS as well as some for disliking it; I won't get into this here), and so these are the focus of what's explored below. My experience with all these toolkits is significantly less than exhaustive (to be generous), so please take it all with a block of salt.

wxWidgets is possibly the best known of the alternatives, especially if you have a Windows background. I've liked working with wxWidgets. Its native language is C++, but it's the second pseudo-defacto standard toolkit for Python (behind Tkinter) and there are plenty of other language bindings available. Integrated GUI design and C++ code development is provided by the multi-platform CodeBlocks IDE with the wxSmith GUI builder plugin. However, the language is once again C++, and I have found using wxSmith somewhat problematic (both with regards to its interface and bugs). I am really looking forward to seeing how the next version of wxWidgets delivers and equally interested in CodeBlocks' development, but it seems to me there's more fire (and money) in the Qt effort at the moment.

GTK+ is the defacto standard GUI toolkit for *NIX systems that are not KDE-based. It is also available for Windows, and an OS X version appears to be in the works. There are lots of language bindings, but the underlying language is C. It is also a GUI toolkit only. (Other kits discussed here offer more than just GUI widgets.) I haven't spent a lot of time with GTK+ mainly because there is no IDE I am aware of that integrates GUI building with coding. Another reason is that GTK+ apps on Windows always look odd if not downright ugly.

Lazarus is a relatively unknown gem in the field of multi-platform toolkits–possibly because it uses the relatively obscure Free Pascal language. But make no mistake, Free Pascal is a real, adult-strength, very powerful language. In fact, many of the constructs that give C++ its power (and problems) have been adopted by FP. Lazarus is essentially a multi-platform Delphi clone, producing fully compiled apps using native widgets whenever possible. (I used Lazarus to develop jIDEE.) The range of widgets and other bits is breathtaking, and the GUI builder integrates with code editing at about the same high level as Visual Studio (or Delphi, on which VS was based). The development team, while not having the backing of Qt, are clearly interested in making good software and are quite active.

In spite of these strengths, Lazarus has a few issues:

• As is the case with Delphi and Visual Studio, the overall design and workflow discourage a clean separation of GUI and processing logic. It can be done, but it's not the most obvious way to do things. This will be a bigger deal to some people than others.
• The project needs a bit more time to mature. As of v0.9.28.2, there are a bunch of not-deal-breaking-but-nonetheless-irritating bugs in the IDE as well as in the generated code. I suspect these will get ironed out in time.
• While it supports quite a few different platforms, it doesn't yet support any mobile platforms (but support for some is in the works).

In spite of these shortcomings, I like Lazarus a lot and eagerly await future releases.

Mono is a multi-platform, FOSS implementation of .NET. It is supported by the MonoDevelop IDE. I have three issues with Mono. First, I've had nothing but headaches trying to use MonoDevelop's GUI builder. Maybe I'm stupid. Maybe it doesn't like me. Maybe both. Second, Mono requires that you have Mono runtimes installed. This isn't a huge issue as all the toolkits discussed here require that you have their respective libraries installed or bundled in your apps. However, Mono is a bit different in that it's really big, and it also uses a virtual machine to run its code (ala Java) rather than running machine native code. Third, there is an outstanding patent issue: while a lot of the stuff that makes up Mono is ECMA standardized, there are lots of classes that are re-implementations of patented stuff in .NET. This has led to a relationship between Microsoft and Mono that is odd (to say the least) and may ultimately work against FOSS goals.

Swing is the standard GUI toolkit for Java and is very well served by the Netbeans IDE. However, Swing apps always look and feel like Swing apps, even when they are trying to look native. In addition, you have the same issues of needing a runtime that you do with Mono. I love the Java language and the richness of its APIs, but the slowness of apps to start and Swing's goofy looks and feels have really limited its appeal for me as a desktop solution.

SWT is an alternative to Swing. While it solves the look-and-feel problem by using native widgets when possible, it still has the Java runtime overhead. It is closely associated with the Eclipse IDE. There are several options for GUI builders for Eclipse, but I have yet to try any of them–mostly because of the other issues associated with Java for desktop development.

As far as desktop programming solutions that are not FOSS, multi-platform, or both, Delphi and Visual Studio come to mind. Both are arguably easier to set up and work with than any of the above–the latter offering a range of programming languages if you don't mind making .NET apps. This ease comes at a cost: neither Delphi nor Visual Studio are multi-platform, and neither encourage you to make a clean separation between GUI and processing logic. (Again, it's possible; it's just not “natural”.) SharpDevelop is a Windows-only FOSS IDE that lets you write .NET applications in a number of .NET languages (Boo, anyone?) and includes GUI building support for most of them. Apple has the XCode suite of tools for OS X and iOS development, but this can hardly be called a multi-platform solution.

Perhaps what really tilted the scales for me was the adoption of Qt as the native platform in Meego and (to a lesser extent) the porting of Qt to Symbian. I really like the idea of Meego and hope it takes off. And if and when it does, I want to be ready to join the party. As a plus, being able to write apps for Symbian (which Nokia just refuses to kill) with very little or no extra learning curve is no small thing as it might provide an effective means to reach users who can't afford more advanced smartphones.

Another factor that was decisive for me is the support that Qt seems to be getting. While the community aspect of Qt support isn't as strong as I'd like it to be, Nokia appears to be giving Qt big hugs and are themselves betting on Qt's future through Meego and (to a lesser extent) Symbian. And lest we forget, Intel is also part of the Meego effort. So, I have some confidence that Qt will be around for a while and remain relevant.

The goal of multi-platform programming is to write once and compile anywhere.¹⁾ This is a huge goal, and one that not unexpectedly is essentially impossible to achieve perfectly. There are just too many differences in the way platforms work–from the OS level up all the way up to interface conventions. This leads to the following statement:

If you plan to develop your project to reach multiple platforms using OneHolyCodeBase™, you must accept compromises.

There are people who tell you this isn't the case. They are lying. There are people who say multi-platform development is doomed to failure. I believe they are lying as well. The simple truth is that multi-platform development based on OneHolyCodeBase™ is possible, isn't perfect, and may not be the best (or even easiest) way for you to solve your multi-platform problem. The key is to develop an understanding of what the limitations (and strengths) of multi-platform programming are, and then apply it when it makes sense. And I can't think of anything but experience to give you this understanding.