I have decided that I need to teach myself Qt in my copious free time. I have 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 leading the list. 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 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 to an LGPL license, and this lets you link to Qt stuff 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 certainly for the present it means I need to make peace with C++ if I plan to use Qt. Again. 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 a few macros and some 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 these are the only solutions 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. There are tons of language bindings, and it's the second pseudo-defacto standard toolkit for Python (behind Tk). The multi-platform CodeBlocks IDE integrates with the wxSmith GUI builder via a plugin. However, the language is 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 comes out, 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 as of this writing 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 Object Pascal language. But make no mistake, Object Pascal is a real, adult-sized, and very powerful language. In fact, many of the constructs that give C++ its power (and problems) have been adopted by OP. 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 logic and business 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 (however, 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 require that you have their respective libraries installed or bundled in your apps; however, Mono is a bit different in that it's huge and uses a virtual machine to run its code (ala Java). 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 not and that are re-implementations of stuff in .NET. Microsoft has in the past objected to this (but they also tacitly seem to be encouraging Mono as it helps to support .NET). The result is that one day without notice Mono might find itself in a huge pile of doodoo and be forced to close shop.

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, but the slowness of apps to start and Swing's goofy looks and feels have really seemed to limit its appeal on the desktop.

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. While there is reported to be a SWT-based GUI builder in the works for Eclipse, I have yet to try it–mostly because of the other issues associated with Java for desktop development.

As far as solutions that are neither FOSS nor multi-platform, Delphi and Visual Studio come to mind. Both are arguably easier to set up and work with than any of the above–the latter in particular 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”.) Apple has XCode and other tools for OS X and iOS development, but this can hardly be called a multi-platform solution and probably never will be.

Perhaps what really tilted the scales for me was the porting of Qt to Symbian and (more importantly) the adoption of Qt as the native platform in Meego. 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. There are just too many differences in the way platforms work–from the OS level up to interface conventions. This leads to the following:

If you plan to develop your project to reach multiple platforms using one holy code base, 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 one holy code base 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.