As far as I know and have understood in my experience with Qt, it's a very good and easy to learn library. It has a very well designed API and is cross-platform, and these are just two of the many features that make it attractive. I'm interested to know why more programmers don't use Qt. Is there a deficiency which speaks against it? Which feature makes other libraries better than Qt? Is the issue related to licensing?
I don't really intend this to be a bashing answer, but these are the reasons I do not personally use Qt. There are plenty of good things to say about it -- namely that the API works most of the time, and that it does seamlessly bridge platforms. But I do not use Qt, because:
|show 31 more comments|
Of all the things I don't like about Qt, the fact that it doesn't play well with templates bugs me the most. You can't do this:
It also doesn't play well with the preprocessor. You can't do this:
That, mixed with the fact that everything that responds to a signal has to be a Q_OBJECT, makes Qt hard to work in for a C++ programmer. People used to Java or Python style programming probably fair better actually.
I actually spent a lot of time and effort researching and devising a way to gain type safety back and connect a Qt signal to any functor object: http://crazyeddiecpp.blogspot.com/2011/01/quest-for-sane-signals-in-qt-step-1.html
The kind of thing I want to do there is basic, everyday C++ development made next to impossible by the Qt moc...which itself is entirely unnecessary now days, if it ever actually was.
Frankly though, I'm stuck with it because if you want to do automated UI testing, Qt is pretty much the only game in town short of MFC...which is so 1980 (it sucks working in that shit really hard). Some might say WX but it's got even more serious problems. GTKmm would have been my first choice but since it's all owner drawn and doesn't do accessibility...can't be driven by industry standard testing software. Qt is hard enough in that regard (barely works when you modify the accessibility plugin).
Some of it is licensing. See http://en.wikipedia.org/wiki/Qt_(framework)#Licensing for some of the licensing history. Until 2000, people who cared strongly about open source, did not use Qt. Period. (This was, in fact, the original motivation for the development of Gnome.) Until 2005, people who wanted to be able to release free software for Windows did not use Qt. Even after that date people who wanted free software under something other than the GPL, simply did not have the option of using Qt. Thus any free software project that is older than those dates, couldn't use Qt. And, of course, people writing proprietary code had to pay for the privilege.
Furthermore for a long time Windows was so dominant on the desktop that a lot of software was content to only run on Windows. If you install the Microsoft toolchain, it is easier just to use Microsoft's proprietary stuff than it is to worry about anything else, and a lot of programmers did just that.
|show 3 more comments|
As people say, each tool fits to each problem and situation...
But if you're C++ programmer, Qt is your framework. No rival.
We develop a complex medical imaging commercial application, and Qt holds on.
I don't say that the 'cons' that people say about it are false, but I have the feeling that they don't have tried Qt for a long time (its continously improving on each new version...) And, mostly all of the issues they comment are not a problem if you take care.
UI platform inconsistency: only if you use the UI widgets 'as they are', with no customization or custom art.
Qt preprocessor overload: Only if you abuse of signal-slot mechanism, or QObject inheritance, when there is no really need.
By the way, We still write applications in C#.NET, and been doing it for a long time. So I think I have enouch perspective.
As I said, each tool for each situation,
but Qt is with no doubt a consistent and useful framework.
The reason is simple: it does not have good bindings to all mainstream languages, and it is not magically always appropriate for the job at hand.
Use the right tool for the job. If I'm writing a simple command-line application, why would I bloat that up with Qt just for the sake of it?
As a more general answer (which I can give because I'm relevant here), some programmers will simply never have given it a go and decided to use it. In some cases there is no particular reason other than the programmer has never found a need for it and looked into it.
|show 2 more comments|
I agree that Qt is a nice framework to work with. Still, there are a number of issues I have with it:
That said, I love using PyQt for rapid application prototyping or in-house applications. Using Python to do all the coding alleviates the concerns with C++ and actually makes Qt a very pleasant place.
Edit, in response to some comments:
When I wrote about Qt being written in C++, I was not so much complaining about Qt itself, but more about the environment it lives in. It is true that Qt manages its own resources very well, but all your GUI-related-but-not-Qt code has to be written in C++, too. Even there, Qt provides many nice tools, but ultimately, you have to deal with C++ at that level. Qt makes C++ bearable, but it is still C++.
As for introspection, what I mean is this: The hardest cases to debug are when you have a pointer to some object that does not behave the way you think it should. With C++, your debugger might be able to look inside that object a bit (if it happens to have type information at thwt point), but even that does not always work. Take, on the other hand, Cocoa in the same situation. In Cocoa/Obj-C, you would be able to send messages ('call functions') to an object right within the debugger. You can change the objects state, you can query it for its attributes, you can ask it for its type and its function names... This can make debugging a lot more convenient. Qt/C++ has nothing even close to that.
|show 12 more comments|
Frameworks like Qt are appropriate when you're more concerned with your product looking the same on all platforms than with your product looking right on all platforms. More and more often these days, those kinds of applications are moving to web-based technologies.
I agree with nearly all of the reasons discussed above however a lot of people here have said they wouldn't use Qt because of the extra overhead that it brings with it. I disagree with that because all the most common languages today (Java, C# and Python) carry a fair bit of overhead themselves.
Secondly, Qt makes programming with C++ so easy and straight-forward that it makes up for the extra resources it uses. I've come across quite a few console applications written in Qt rather than standard C++ because of the ease in which they can be written.
I would say that the productivity of Qt is greater than that of C/C++ but less than languages like Python.
One reason to not use Qt is that if you only write for one architecture, such as Windows, you may want to use C#/.NET (or Cocoa on Mac) because they will invariably be able to take advantage of the latest bells-and-whistles of the OS.
If you are writing cross-platform apps, then you may already be heavily vested in another technology such as Java (i.e. you work in a "Java Shop"). Your choice of technology might be dictated by the ecosystem in which you are developing, such as language-specific APIs. In these sorts of cases, minimizing the number of technologies may be beneficial.
A third reason that I can think of is that Qt is based around C++, and C++ is a comparatively difficult/dangerous language to program in. I think it is a language for professionals. If you need to have top performance and are capable of being meticulous, then C++ is probably still the best game in town. Actually, Qt ameliorates a lot of the memory management problems if you set things up to fall out of scope. Also, Qt itself does a good job insulating the user from a lot of the nasty C++ issues. Every language and framework has its pros and cons. It is a very, very complicated issue that usually can be summarized by the addage often seen in diners: Speed, Quality, and Price (but you can only pick two).
Although the rules say I should keep focused on answering the question, I do want to rebut some of the issues raised by Billy ONeal, who I think does a good job summarizing the commonly cited reasons to not use Qt:
In summary, it's a complicated issue. But I would like to point out that I think there are less reasons to "not use Qt" as one might think based on myths and decade-out-of-date information.
The actual reason is not technical.
People happen to be different. So are their choices. Uniformity is not a human feature.
This genuinely isn't an attempt to start a flame war, I just wanted to address some of the points.
Probably the real reason that Qt isn't more widely used is that it's C++ and fewer people use c++ for desktop apps.
The vs-addin for visual studio does this automatically as does Qt's own commandline make process. The resource compiler used to build the dialogs for MFC is also a separate step but that's still c++.
There is a binary download for each version of visual studio and the build from source is a single command. I don't see SDK source size is so much of a deal these days. Visual studio now installs all the C++ libs rather than letting you pick and choose, as a result the install size of the compiler is >1Gb.
The LGPL only applies to the lib, it doesn't affect your code. Yes it means you have to ship DLLs rather than a single binary (unless you pay), but in a world where you need to download a Java runtime or a .Net update for a tiny util this isn't such a big deal. It's also less of a problem on platforms with a single ABI so that other Qt apps can share the libs.
It's supposed to use native widgets and themes. I must admit I do mostly technical apps so my users aren't too concerned about style. Especially on windows the new fashion for having everything style itself as a smartphone widget means that there is less and less of a standard anyway.
The most important but not mentioned thing. In big project one thing causes so much problems and non necessary code. Qt's signal slot mechanisms is inefficient. Qt widgets does not provide necessary signals for event simple widgets. For example you can not set signals for onHover, onMouseEnter, onMouseLeave, onKeyReleased, onLostFocus, onGainFocus and etc. Even the most complex widget such as QTreeWidget does provide one or two ultra simple useless signals.
Yes, you can use events BUT !!! you have create new class for each widget with custom event. This is huge efficiency lost;
One of my college has wrote made new combo box class for each combo box widget because he had to use some non signal event. True story...
However, Qt is the best C++ UI framework so far with downs and ups.
I really like Qt, but it's a bit heavyweight for a lot of applications. Sometimes you just don't need that level of complexity. Sometimes you just need something simple without all the overhead of Qt. Not every application needs to be event driven and C++ provides a reasonable set of templates. Boost provides another very good set and includes a lot of the low-level functionality (file, socket, managed pointers, etc) that QT does.
Other applications have licensing requirements that don't play nice with GPL, LGPL or Qt's commercial license. The GPL is inappropriate for commercial software. The LGPL is inappropriate for statically linked software and the commercial license costs money - something that many are unwilling to pay.
Some have security or stability considerations that don't allow complex libraries like Qt.
You need to run moc to pre-process your sources. That's not a huge issue, but it can be daunting for the new user. A lot of programmers think you need to use qmake with Qt, but that's a misnomer. It is possible to plug Qt into other build systems pretty easily.
Some targets are very memory or CPU constrained.
There some platform-specific gotchas in it. Most of those gotchas are undocumented. Build a sufficiently large application and you will run into them and wonder what's going on (disclaimer, the last time I used Qt in anger was over 18 months ago, so it may have improved).
It's C++ only. Other language bindings exist, but they tend to hide or poorly expose a lot of the functionality that you'd want Qt for.
There's a lot of reasons to not use Qt, that's why there are alternatives. If all you have is a hammer then every problem will look like a nail.