Why aren't more desktop apps written with Qt?（quora.com系列文章）

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?

api libraries qt
shareimprove this question

closed as primarily opinion-based by gnat, Dan Pichelman, MichaelT, thorsten müller, mattnz Sep 20 '13 at 8:22

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.
 
50  
It's native C++. Most developers would prefer higher level languages such as C#. – user16764 Jul 1 '11 at 6:25
6  
Bindings to the languages other than C++ are either incomplete, clumsy or do not even exist. Only the Python bindings seems to be ok. – SK-logic Jul 1 '11 at 6:26
10  
The two-edged sword of backwards compatibility has left Qt with many anachronisms, unfixable defects, and other poor behaviour. – edA-qa mort-ora-y Jul 1 '11 at 7:59
21  
@user16764: "Most"? – Lightness Races in Orbit Jul 1 '11 at 9:09
10  
I don't think the TIOBE index is a really accurate measure, because it measures popularity, not use. Comparing amount of code in open source repositories like GitHub, Bitbucket, Codeplex, and Sourceforge would give more accurate measurements. (And I believe those more accurate measurements put C and C++ in #1 and #2 spots -- Java has an unfair advantage in the TIOBE index because it's used for freshman college courses, and new programmers make more buzz than experienced ones do) – Billy ONeal Jul 1 '11 at 17:22

14 Answers

up vote150down voteaccepted

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:

  1. In some cases, it just doesn't look like native programs look. Designing a single UI for all platforms inherently is not going to look right when moved from machine to machine, for various visual styling reasons. For example, on Mac machines, split bars are usually relatively thick, and buttons are small and rounded with icons. On Windows machines, split bars are typically narrow, and buttons are more textual, with more square designs. Just because you can write one UI for every platform does not mean that you should for most applications.
  2. Qt is not a C++ library. It requires a separate compilation step, which makes the build process much more complicated when compared with most other libraries.
  3. As a result of (2), C++ IDEs and tools can flag Qt expressions as errors, because they do not understand Qt's specifics. This almost forces use of QtCreator or a textual only editor like vim.
  4. Qt is a large amount of source, which must be present and preinstalled on any machine you use before compiling. This can make setting up a build environment much more tedious.
  5. It's available only under LGPL, which makes it difficult to use single-binary-deployment when one needs to release under a more restrictive or less restrictive license.
  6. It produces extremely large compiled binaries when compared with similarly written "plain ol' native applications" (excepting of course applications written for KDE).
shareimprove this answer
 
10  
@Dehumanizer: There's the LGPL license, and there's the commercial license. The commercial license is thousands of dollars on the part of the licensee, and does not allow redistribution, etc. For open source projects under liberal licenses like BSD, MIT, or Boost, where the authors aren't making tons of money and they wish to release their code under a liberal license, a dependency on LGPL is unreasonable, but the developers in question generally cannot afford commercial licensing. – Billy ONeal Jul 1 '11 at 6:37 
26  
#6 is the biggest reason I avoid it. I mean, I don't want a big, clunky program, and I don't like being bound to a specific license, but it's really the lack of a good, native look-and-feel that's a deal-breaker for me. Recent versions of OSX and Windows specifically have done a fantastic job of making their native interfaces pretty, fast, and functional, and I'd rather leverage all the work they've already done for me; I find that many programs without a native look feel cheap and hacky to me (not always, but it wierds me out a bit). – Greg Jackson Jul 1 '11 at 7:24 
15  
Your number 6 should have been number 1. This is by far the biggest problem with Qt. In many cases, it simply does not use the native APIs. I like my software to look native. Users like that, too. I've never seen a Mac application created with Qt that looked like a Mac application. Neither have any other Mac users, and they're picky about that sort of thing. You lose all the benefit of it being "cross-platform" if you're only using it to create Linux applications, which is about the only place it looks native because there really is nothing native. – Cody Gray Jul 1 '11 at 9:07 
33  
except the problem of the 'native' look is no longer there. The old consistency of Windows apps is now a bastardisation of whatever unique blobs, glows and animations WPF and silverlight let you have. Take a look at Office or Windows 7's Control panel just to see how even MSs flagship product has inconsistent GUI nowadays. Mac users - well, you have very valid a point there. – gbjbaanb Jul 1 '11 at 9:19
5  
@TrevorBoydSmith: Sorry, but you're wrong. Qt is the only framework that uses preprocessing. Period. Check GNOME, FLTK, WX, and friends, and show me a preprocessing step. You won't find one. Some other libraries come with different build systems, but at the end of the day, they are C++ libraries which can be built by any C++ compiler. As for "Raw win32 not present in my reasons", it is present in my reasons as #5 and #6. – Billy ONeal Oct 14 '11 at 17:05 
up vote81down vote

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.

shareimprove this answer
 
6  
+1 Thaks! I just wanted to writ the same. The most nonsense is "non open source/commercial argument". Astonishing, how wrong many people understand the term Open-Source. Qt was Open-source since I use it (1.4). And it used to have the most fair license: earn money with Qt -> pay. – Valentin Heinitz Apr 16 '13 at 10:26
10  
Oh and I really don't CARE about adding 10 MB DLLs to application containing 50 MB of art and 200 more MBs of video tutorials and data :) – Петър Петров Aug 17 '13 at 20:33
6  
The space needed for Qt is cheap these days. – trusktr Jan 30 '14 at 4:21
2  
This pretty much matches my experience with Qt (the widgets framework, I haven't used QML / QtQuick for anything serious so far). It is suitable to write large applications with complex UI requirements. Once you learn it, you can be very productive. The cons mentioned (seperate compilation step for moc ing, ui files, etc) are not a problem if the build system is properly set up. I can recommend either qmake or cmake. – NilsDec 9 '15 at 9:46
up vote31down vote

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:

template < typename T >
struct templated_widget : QWidget
{
  Q_OBJECT;

public signals:
  void something_happened(T);
};

It also doesn't play well with the preprocessor. You can't do this:

#define CREATE_WIDGET(name,type) \
struct name ## _widget : QWidget \
{ \
  Q_OBJECT; \
\
public signals: \
  void something_happened(type); \
}

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).

shareimprove this answer
 
1  
Out of interest, what do you see as the main problems with WX? – Tom Anderson Jul 1 '11 at 11:33
5  
@Tom - poor documentation, especially for the new stuff. The AUI components are barely documented at all with large sections missing, making it difficult to use in a production environment. The documentation for the event process is fundamentally in error with regard to the path that is followed, on win32 at least. Spent a lot of time yelling at the computer, "This should be working!!!" before getting down into the deep processing code to find out that what WX does isn't following the docs and what I was doing would NEVER work. – Crazy EddieJul 1 '11 at 16:57
    
I was also disturbed by the acceptance of the property grid library into the main line. I used that library and it showed numerous, fundamental design flaws in addition to actual lack of knowledge on behalf of the programmer who wrote it (called virtual functions in constructors for example). It, and the poor state of AUI, showed a trend to poorer standards. I'm also not a big fan of static event tables, though at least there's another way to respond to events...unlike MFC, which WX is just too much like to be exciting anyway. – Crazy Eddie Jul 1 '11 at 16:59
    
Thanks. I've only used it a bit, and through the wxPython API, where it seemed quite nice. I can appreciate that that would hide some of the evil, but also that i just haven't got deeply enough involved to have come up against the more serious problems. Something for me to be aware of. – Tom Anderson Jul 1 '11 at 17:38
    
While I agree with your observation, and that Qt is certainly not about code quality, I do not understand your last paragraph about automated UI testing. The standard Windows controls implement the UI Automation interfaces, better than Qt ever will. "Native" Windows API programming as well as any framework encapsulating native controls (like MFC, or WTL) suits itself for standard UI testing. Can you expand on that?– Tim Apr 25 '14 at 22:42
up vote22down vote

Some of it is licensing. See https://en.wikipedia.org/wiki/Qt_(software)#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 it is not as it there is a shortage of other options. For instance WxWidgets, GTK+, and Tkare all open source, cross-platform toolkits.

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.

shareimprove this answer
 
1  
@btilly: GTK+ is cross platform. For example, the Pidgin IM client is written on GTK+. – Billy ONeal Jul 1 '11 at 6:42
1  
Ok, however, it is possible 'somehow' to run on Windows:) – Dehumanizer Jul 1 '11 at 6:43
5  
Just install GIMP on Windows and have a look. – user281377 Jul 1 '11 at 7:37
2  
Yeah, and GIMP works well on Windows, but it certainly doesn't fit in with the Windows 7 UI look & feel. – Alan B Jul 1 '11 at 8:38
4  
Pidgin is probably a better example of GTK on Windows. It doesn't do anything fancy, but it fits in and has for maybe 10 years or more? – Brendan Long Jul 1 '11 at 16:22
up vote20down vote

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:

  1. Qt is indeed a C++ library/framework/header files. It is augmented by a macro processor (moc) which enables signals and slots, among many other things. It transforms additional macro commands (such as Q_OBJECT) so that classes have introspection and all sorts of other goodies that you might think of as adding Objective-C functionality to C++. If you know enough about C++ to be offended by this lack of purity, i.e. you are a pro, then 1) don't use Q_OBJECT and its ilk or 2) be grateful that it does this, and program around the very limited corner cases where this causes a problem. For folks who say "Use Boost for signals and slots!" then I would retort that you are exchanging one "problem" for another. Boost is huge, and it has its own commonly-cited issues such as poor documentation, horrendous API, and cross-platform horrors (think old compilers like gcc 3.3 and big iron compilers like AIX).

  2. For editor support, this also follows from 1, I somewhat agree. Actually, Qt Creator is IMHO the best graphical C++ editor, period, even if you don't use the Qt stuff. Many professional programmers use emacs and vim. Also, I think Eclipse handles the additional syntax. Thus, no problems with the Qt macros (Q_OBJECT) or signals/slots additions. You will probably not find these macros in Visual Studio, because (I concede) they are additions to C++. But by and large, C#/.NET folks aren't going to be using Qt anyway, due to the fact that they have a lot of the functionality covered with their own proprietary techniques.

  3. As to the size of the Qt source, so long as it compiles overnight, who cares? I compiled Qt 4 on my dual core Macbook in "less than overnight." I certainly hope this is not what is driving your decision to use or not use a particular technology. If this is truly a problem, then you can download the precompiled SDKs for Mac, Linux, and Windows from the Qt website.

  4. Licensing is available in three choices: 1) Proprietary license in case you wish to modify QtITSELF and not share, or hide the fact that one is using Qt and not willing to give attribution (could be very important for branding and image!) 2) GPL and 3) LGPL. Yes, there are issues with static linking (rolling all of Qt into the binary) -- but I think that's more because one can't peek inside and notice that you are using Qt (attribution!). I tried to buy a proprietary license from Digia, and they told me "for what you are doing, you really don't need it." Wow. From a business who is in the business of selling licenses.

  5. The size of the binary/bundle is because you have to distribute the Qt stuff to folks who don't have it: Windows already has? the Visual Studio stuff or you have to install the run-time. Mac already comes with the enormous Cocoa, and can be dynamically linked. Though I don't do a lot of distribution, I have never found much issue with distributing the ~50 megabyte static file (which I can make even smaller with some of the binary stripper/compression utilities like UPX). I just don't care enough to do this, but if bandwidth were ever an issue, I would add a UPX step to my build script.

  6. What defines "Native Look and Feel?" I think "most" would agree that Mac comes closest to unified look and feel. But here I sit, looking at Safari, iTunes, Aperture, Final Cut Pro, Pages, etc. and they look nothing alike despite the fact that they are made by the OS vendor. I think the "feel" aspect is more relevant: widget styling, responsiveness, etc. If you care about responsiveness, then here is a good reason to use C++ rather than Java, or some other highly dynamic language. (Objective C also rocks, but I'm trying to dispel myths about 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.

shareimprove this answer
 
1  
What I don't get is why these cross platform libraries aren't simply wrapper functions, or even better; if defs around Cocoa, Win32, KDE/Gnome functions, ensuring the best looking UI, with all of it's features. – MarcusJJul 10 '15 at 10:44
1  
@MarcusJ Writing a wrapper around one toolkit is distinctly non-trivial, never mind 4 or more - but if you think it's that easy, you're welcome to try. As for the idea that this could be achieved using only conditional preprocessing... you must be joking, right? – underscore_d Feb 17 '16 at 22:33 
    
@MarcusJ libui is exactly that (though without KDE support). – Demi Feb 27 at 0:32
up vote10down vote

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.

shareimprove this answer
 
1  
I guess it's all relative to the individual's experience, because I can code OK in C++14, but every time I glance at some Qt code, I have to squint hard to recognise it as the same language... so I certainly don't think it's the unanimous productivity booster you're implying here. – underscore_d Feb 17 '16 at 22:35 
up vote7down vote

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.

shareimprove this answer
 
9  
@Dehumanizer: I have no idea. But why would I use it for a small utility tool? What benefit would that bring to me when I can trivially write the application in just standard C++? Seems you're looking for a reason to use a library, which is a backwards way to program. – Lightness Races in Orbit Jul 1 '11 at 9:20
11  
@Dehumanizer: As I said, that's a backwards approach. When you find a need for a library, you'll know, and then you can go and try a few out and see what fits your need better. Trying to gather opinion on a librarywhen you don't have a use case is a fool's errand. – Lightness Races in Orbit Jul 1 '11 at 10:15
1  
"What benefit would that bring to me when I can trivially write the application in just standard C++?": I know it is a matter of taste (and this can start a holy war), but Qt collections (e.g. sets) are often more intuitive and usable than the standard ones. – Giorgio Nov 20 '12 at 21:02
3  
"If I'm writing a simple command-line application, why would I bloat that up with Qt just for the sake of it" there is at least one very famous non-gui tool written in Qt - Doxygen :-) – Valentin Heinitz Apr 16 '13 at 13:36
4  
@Dehumanizer for example when you have to deal with files, xml, unicode, json, regexp, concurency, databases, etc,etc, very fast and don't want to download, adopt, maintain dozen 3rd party libraries. – Valentin Heinitz Apr 16 '13 at 13:40 
up vote6down vote

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.

Qt is not a C++ library. It requires a separate compilation step, which makes the build process much more complicated when compared with most other libraries.

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++.

Qt is a large amount of source, which must be present and preinstalled on any machine you use before compiling. This can make setting up a build environment much more tedious.

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.

It's available only under LGPL, which makes it difficult to use single-binary-deployment when one needs to release under a more restrictive or less restrictive license.

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.

In some cases, it just doesn't look like native programs look. Designing a single UI for all platforms inherently is not going to look right when moved from machine to machine, for various visual styling reasons.

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.

shareimprove this answer
 
1  
Quite a lot of large software companies build commercial applications in C++ but I'm not aware of very many that use QT. So, while I understand that non-C++ developers might avoid QT, there are other reasons to avoid QT even when you are writing a C++ app, it would seem. In fact, there really isn't any cross platform language and GUI toolkit that I can't find fault with. It seems that cross-platform development is JUST PLAIN HARD, and that doing it well is never easy or free, and that the promise QT makes (Write your GUI once and reuse that GUI everywhere) isn't enough. – Warren P Nov 20 '12 at 19:45 
    
Most desktop C++ software is either in MFC because it started 20years ago or uses an internal toolkit started 20years ago to avoid MFC (eg MS-Office or Autocad). I doubt very much is being written in C++/CLR with WPF. But even without cross-platform considerations I find Qt the best (or least worst!) desktop toolkit. Like most people we are moving toward a webby front end (possibly in QtQuick/QML) and a C++ server backend - which will probably use Qt signals/slots but no gui – Martin Beckett Nov 20 '12 at 19:52 
    
I agree. Least worst. And even on Windows-only apps I'd rather debug QT issues than MFC issues. – Warren P Nov 20 '12 at 20:02
    
@WarrenP - yes I don't miss searching codeproject for all the stuff missing from MFC. But with MSFT's new found love of native code - they haven't done much to make writing a gui any easier. – Martin Beckett Nov 20 '12 at 20:40
up vote4down vote

I agree that Qt is a nice framework to work with. Still, there are a number of issues I have with it:

  1. It is written in C++, which is a really low level language. The fact alone that it is C++ will make every Qt programmer significantly less productive compared to Frameworks written in other languages. My main beef with C++ as a GUI development language is that it has next to no notion of automatic memory management, which makes the development process a lot more prone to errors. It is not introspective, which makes debugging a lot more difficult. Most of the other major GUI toolkits have some notion of automatic memory management and introspection.
  2. Every cross-platform toolkit suffers from the problem that it only ever can implement the least common denominator of all supported platforms. That, and different UI guidelines on different platforms very much questions the desirability of cross-platform GUIs at a whole.
  3. Qt is very much centered on coding up all your UI. Even though you can use QtDesigner to build some parts of your UI, it is seriously lacking in comparison to, say, (Cocoa/Obj-C) Interface Builder or the .Net tools.
  4. Even though Qt does include a lot of low-level application functionality, it can not compare to having a framework hand-tailored for a certain platform. The native operating system libraries for both Windows and OSX are significantly more powerful than Qt's implementations. (Think audio frameworks, low level file system access etc.)

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.

shareimprove this answer
 
10  
1. Qt cares of memory management on its own, you have not to call 'delete' after each 'new'. 1a. C++ is NOT low level language, it is high level language with low-level 'abilities'. 3. I agree, but Qt provides to make a UI with QtDesigner and with 'plain code' in same time. 4. Agree again, but Qt also provides to use native APIs.– Dehumanizer Jul 1 '11 at 11:47 
11  
to your point nr 1. I think c++ does have kind of semi-automatic memory management: if you use smart pointers like std::auto_ptr or boost::shared_ptr etc. you generally dont have to care about freeing memory. These kind of containers can be made for other resources as well (files, system resource which have to be freed). Use of RAII-pattern helps very much with memory management and as it grows into you, you dont really have to worry about memory. – deo Jul 1 '11 at 12:38 
7  
"The fact alone that it is C++ will make every Qt programmer significantly less productive compared to Frameworks written in other languages." [citation needed] – Nathan Osman Jul 3 '11 at 22:08
4  
@SK-logic: While I think I understand all the words in your third sentence, I have no idea what you are saying. What is a "level of abstraction cap"? For that matter, your first sentence is false, given the Wikipedia definition of "low-level language". – David Thornley Oct 19 '11 at 14:46
5  
@SK-logic: Template metaprogramming is Turing-complete, and there are people smart and knowledgeable enough to take advantage of that. RAII isn't great garbage collection, but the fact that it works for all sorts of resources more or less makes up for that. Now, specifically, what sort of abstraction works in Java but not C++? – David Thornley Oct 19 '11 at 20:15
up vote4down vote

Frameworks like Qt are appropriate when you're more concerned with your product looking the sameon 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.

shareimprove this answer
 
up vote3down vote

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;

  • You have rewrite each customized widget object event there is small changes.
  • You lose all of Qt Designer stuff. You have to promote every widget with custom events.
  • Project became bigger and hard to maintain.
  • You started dislike qt because of this. And starting to talk about how .net provides delegates, how it is much much much more better than signal slot, how .net components (widgets) generally provides every event that you can imagine. And etc.

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.

shareimprove this answer
 
    
Regarding events and creating new classes: you can use event filters in classes that need to react to them. – MrFox Nov 20 '12 at 17:47
    
"Yes, you can use events BUT !!! you have create new class for each widget with custom event. This is huge efficiency lost;" - NOT EXACTLY. I just end up with bool eventFilter that handles several widgets and then installEventFilter(this) on all the child widgets. And this isn't losing efficiency and programming performance! Actually I Never use "Promoted widgets"... I drop just plain empty widget, install this as eventFilter on it and reimplement most of my events within my main cpp class. Try it, didn't pain :) You can customize almost EVERYTHING in Qt without creating new classes everytime – Петър Петров Aug 17 '13 at 20:39 
up vote2down vote

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.

shareimprove this answer
 
up vote1down vote

on my own opinion, learning C++ programming is simpler than falling into other languages that hide their complexity, and programmer does not know what really happens in background. Qt on the other hand, adds some benefits over C++, to make it higher level than native C++. Thus Qt C++ is a great framework for who wants to develop low-level tasks, or high-level ones, with a same manner. C++ is (by some practices) a complex and simple language. Complex for who wants not to challenge with it, simple for one who likes it. Don't leave it for it's complexity!

shareimprove this answer
 
up vote0down vote

The actual reason is not technical.

People happen to be different. So are their choices. Uniformity is not a human feature.
 
https://softwareengineering.stackexchange.com/questions/88685/why-arent-more-desktop-apps-written-with-qt

 

posted @ 2017-08-31 05:17  findumars  Views(1403)  Comments(0)  Edit  收藏  举报