Why aren't more desktop apps written with Qt?

  • 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?

    It's native C++. Most developers would prefer higher level languages such as C#.

    Bindings to the languages other than C++ are either incomplete, clumsy or do not even exist. Only the Python bindings seems to be ok.

    The two-edged sword of backwards compatibility has left Qt with many anachronisms, unfixable defects, and other poor behaviour.

    @Tomalak: A quick look at the TIOBE index should help ;)

    @back2dos: Funny, that table implies to me that _all_ the higher-level languages (OK, debateable about Java) are _less_ popular than C and C++.

    @user16764: What you mean by saying higher level languages, isn't C++ a high-level language? Of course it provides low-level 'functionality', but that's a 'feature' which can be ignored and used only high-level mechanisms. Can you, please, give an example where C# is higher than C++?

    @Dehumanizer: I suppose what he means is *managed languages*.

    @Tomalak: What it also says is that those two together take up 25%, while the higher level-languages in that list take up 55%, (the total being 84%).

    @Dehumanizer: It's all relative of course, but C++ is considered a "low-level language" where something like C# or PHP would be a "high-level language".

    @back2dos: True. Well, ok, how about developers don't necessarily prefer higher-level languages, but there may simply be more demand for work in them.

    @Tomalak: Possibly, yes. As I pointed out to Dehumanizer, I think the keyword is *managed* here in fact. I can only speculate, but I believe many programmers prefer the comfort and safety of that.

    @back2dos: I have no grounds on which to suggest that you're wrong, but I certainly _hope_ that that is not the case! :)

    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: In fact GitHub has the only statistics I found, which puts C & C++ a lot further behind. Anyways, the question here was actually about popularity (as in number of developers) and not use (as in amount of code). Of course the number of searches is not necessarily proportional to the number of developers, but it is an indicator.

    ohloh.com has some very nice metrics for this sort of thing - https://www.ohloh.net/languages?query=&;sort=total

    @BillyONeal If you compare the amount of code, then you may give an edge to the languages that exist for a longer time but not necessarily are popular now. And also code in open source projects doesn't necessarily reflect the languages used in production. There is no accurate measure, you just have to select some parameter and stick to it.

    TWO apps I use every day: TortoiseHG is written using python wrappers for QT. kdiff3 is a diff/merge tool for both linux and windows, written in C++ using QT. Two is a lot.

    "Can you, please, give an example where C# is higher than C++?": Garbage collection: in C++ you have to manage memory yourself, C# abstract away from this and has memory management built into the language (AFAIK, I am not a C# programmer, you do not have to program memory management in C# explicitly).

    @Giorgio: Why are you managing memory manually in C++? You shouldn't be. Make `shared_ptr` / `unique_ptr` do that instead.

    Exactly: you have to use `shared_ptr` or `unique_ptr` explicitly to implement memory management. In C# you do not need it: you just create objects and use them. In this sense, C# has a higher abstraction level.

    @Giorgio: Erm, you do have to think about such things in C#. The concept of "who owns this" goes far beyond "who calls `delete`". The fact that the smart pointers make that explicit isn't a language failing; and if you don't think about such things you are going to generate garbage in any high level language I've seen too.

    @Billy ONeal: (BTW, I am a C++ programmer) Of course you will have to think about how much data you allocate in any language (even Lisp, Haskell, etc) because they are all executed on the same underlying computer. I did not say that using explicit memory management is a failing of C++, I am saying that it is less abstract compared to a language in which it is done automatically. In C++ you can better optimize memory management, but you have to program it yourself (lower abstraction level), in other languages this is done implicitly by the runtime, which can have performance costs, of course.

    @Giorgio: I'm not talking about memory management at all when I speak of ownership. I'm talking about "who is allowed to read from or write to this data structure" kinds of ownership. Your argument for "language x is more abstract than language y because it has feature z" is nonsense. C# doesn't have `const`, which makes it difficult to express immutability constructs in that language. Does that mean C++ is "more abstract" than C#? No. Abstraction is not a series of levels that languages need various features to achieve.

    My argument is that C# has automatic garbage collection, in C++ you have to add / implement it (this feature nonsense seems to be widely accepted, see Wikipedia: "In computer science, abstraction is the process by which data and programs are defined with a representation similar in form to its meaning (semantics), while hiding away the implementation details.", http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29). Therefore, wrt memory management, C# is more abstract than C++.

    @Giorgio: Notice that your argument gets moot the second that IDisposable is involved. Especially compared to C++'s stack based allocation, which doesn't require you AT ALL to think about anything...

    "doesn't require you AT ALL to think about anything...": Then we should abolish smart pointers and similar constructs, since they are not needed.

    "done implicitly at runtime" should be replaced with "done POORLY at runtime", most gc sucks for the most part and at best case, only gives you half the optimization you would normally get on your own, and lets not get started down the cache miss/page fault road of the conversation--YIKES!

    Frankly compatibility is definitely not something that Qt is famous for. Even the developers (currently Digia) have stated on multiple times (see some of their presentations) that they do not guarantee even compatibility between minor releases. I haven't experienced issues like this but I know people who have. This alone is a huge put-off for developers who require predictability and stability.

    It is not used because ignorance about Qt and modern C++

    I started using it in a commercial setting with C++, recently. I used PyQt in the past, which was fairly solid. My gripes aren't deal-breakers, but they're valid. Qt community is full of #$%$^#^!-holes, so asking for help at their forums is just asking for someone to come by and say, "read the documentation noob", or along those lines. Code snippets are sparse, while generic documentation is gigantic, which just exacerbates the issue. It also does not play well with STL, but since it pre-dates STL, that shouldn't be too surprising. All-in-all I like it, but I have no C++ alternative, really.

    The best dictionary software I have ever seen, GoldenDict, is written in Qt. So is TeXstudio, the best TeX editor IMHO.

  • Billy ONeal

    Billy ONeal Correct answer

    9 years ago

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

    I see, but isn't Qt dual-licensed?

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

    Ok, understand. Do you know how much the commercial license costs?(It is very interesting to me:)

    Great answer. 3 and 5 are the biggest concerns for me -- building takes forever on my poor laptop!

    @Dehumanizer: Last time prices were published, it was in the couple thousand dollars per seat. Now it seems they don't publish prices and you have to contact them first. I'm not sure what current prices are but I see no reason they would have gone down.

    @Dehumanizer: Bigger concern (at least for me personally) is that even if I purchase a commercial license, those who would wish to use my software's source would need to purchase commercial license for themselves. (Hell, I bought Visual Studio and Visual Assist X and VIEmu, a combined price around the same as Qt)

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

    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.

    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.

    @Cody: I really wasn't putting these in priority order. I was just making a list. The only reason I used an ordered list instead of an unordered list is because #2 had to refer back to #1 somehow.

    Good points, but I disagree with #3. You can download a .bin file from Qt's website and not compile the source.

    @Chance - I don't believe they provide VS builds. Yes, you need compiler specific ones or linking doesn't work. Also, you really need to change the compiler options anyway as Qt builds with /Z:wchar_t-, which breaks compatibility with almost everything else that exists anywhere.

    @Crazy, you may be right, I see a Windows Installer, but I'm not familiar with VS and all that.

    @gbjbaanb: I guess we can agree to disagree on that point.

    @TrevorBoydSmith: Most large frameworks do not have separate precompilation to deal with. You can add most any library to any project by simply adding in that library's .h and .cpp files. Even large libraries.

    @TrevorBoydSmith: And reasons 1 and 2 are all Qt specific. GNOME, wxWidgets, Ultimate++, FLTK and friends do not require seperate preprocessing. They are all cross platform widget toolkits and they're all large, but none uses preprocessing. Sure, reason 3 is just code size, and that's true for a lot of frameworks. But just because other frameworks also have this disadvantage does not mean it's not a disadvantage of Qt -- it's a disadvantage of all such frameworks. Most of the code I write is raw Win32. Adding several MB dependence on Qt for a 200k app would be insane.

    @BillyONeal, (Sorry I edited/deleted previous comments...) Your #1 through #3 reasons are true for any large framework (1. frameworks often have different ways of building code which can be more complicated. 2. frameworks 99.99% of the time won't work with a pre-existing IDE unless the IDE is designed to work with the framework. 3. most 'large frameworks' are... by nature large.). I would summarize #1 through #3 as just stating that it is a large framework and therefore has some hassles/constraints.

    @BillyONeal if "Most of the code I write is raw Win32" is a significant concern for you (but strangely is not present in your reasons...) then definitely do not use Qt... because IMO one of the main reason to use Qt is cross platform support.

    @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 - ;-) but wxWidgets does use preprocessing - event tables are constructed using macros and other preprocesser stuff.

    @Steve314: That's the C preprocessor. It's still C. You don't need to modify your build system for that.

    @Billy - hence the ";-) but ...".

    @Nemanja Trifunovic define "poorly designed", as it seems that you're saying "it is not designed as I would design it, and it is only good way to do it".

    @Crazy Eddie they do provide both VC and mingw binary builds for windows. Also they provide VS integration tool that does all the "preprocessing stuff"

    By popular demand, I have made my #1 item the previous #6 item./

    @BillyONeal - unfortunately that edit makes reading some of the comments confusing as they refer to the old numbers. Maybe you should start with #0? As any good programmer would :).

    @SteveFallows: If I do that markdown just converts it back to 1. :) (It gets emitted as an `

      `)

    OP: Bash away, you certainly wouldn't be the only one that's not a big fan of Qt... :-)

    @Giorgio: I never said using Visual Studio was impossible. The word "almost" was not optional. But you will confuse Intellisense and other such features because they are driven by a standard C++ frontend; not one that understands Qt.

    `Qt is not a C++ library` This must be for an old version, then. I've never had to pre-process my code for QT...

    @Qix: You've never had to use `moc`? That is a preprocessor.

    Ah, this explained it. I've never overridden `QObject`.

    @BillyONeal Good descriptive answer Billy but how you managed to get 70+ up-votes is bewildering to say the least. I can only imagine there are some hard core native enthusiast here. But the reality is from what I've seen the QT framework is the closest to the .NET in terms of productivity, plus you can get most of the native performance benefits, AND you get cross-platform benefits. I do agree with #2 though, but this is kind of unavoidable for a large cross-platform native framework.

    @annoying_squid: As I said in the answer, I don't intend this to be taken as a "don't use Qt" bashing party. The question says "why might someone not use Qt", and I provided reasons why someone might choose to not use Qt. For many applications, Qt is wholly appropriate, and if your application(s) fall into that category, more power to ya. All nontrivial systems (be they Qt, C++, native UI frameworks, WxWidgets, whatever) have problems; balancing these problems against one's requirements and choosing the right system(s) to use is just a part of software design.

    @annoying_squid: Also, I'm not sure how a separate preprocessor is "unavoidable" for large C++ libraries; e.g. Boost does just fine without them.

    Qt Looks NON-NATIVE on Mac because most Qters aren't UI Designers or just can't/don't know how to tweak their UI to make it Mac frienfly. There are Qt Stylesheets, and if you really hate how some control looks weird, use the stylesheets and make it look better. I end up having Windows Qt CSS and Mac Qt CSS all the time and single IFDEF / Platform check to load the proper stylesheet. With these you have one of the BEST EVER features of Qt: Skinning. A feature everyone forgets about. With Qt you can make non-native looking apps as well as native looking ones - it's just how you use this.

    @ПетърПетров: If I am not mistaken, skinning is a feature more recent than this post. (That's a Qt Quick thing, right?) Even if not, that doesn't change my point -- Qt doesn't really solve the cross platform UI problem. If each platform needs ifdef'd UI you might as well just use the native APIs available on that platform.

    @AnnonomusPerson you've got to be kidding, right? Qt is anything but poorly documented.

    @Shf I can't even dynamically change the properties. Can't even use a webelement to go to another page. I've even tried Googling it.

    @AnnonomusPerson what do you mean by changing properties dynamically? Change widget geometry, style etc in runtime? It's should be easy enough, if you ask it on SO, it will be solved immediately. Personally i didn't work with QWebElement, but frankly, seen a tons of examples and it was not something extra hard or special. Just give it some time to learn more about qt and c++ (it's not THAT different from plain c++).

    @Shf Can't find anything online. Can you find anything? If so, I would like to see it because I can't find anything for the QWebElement changing the geometry. I know I can get an answer on SO, but *you've got to be kidding, right? Qt is anything but poorly documented.* It seems like a good platform with lots of features but no standard documentation that's up to date that I can find.

    @AnnonomusPerson: I don't think your criticism here makes sense -- there are dusty / shady corners of every library. The question is talking about systematic problems with Qt as a whole, not problems with a specific component. (You also appear to be trying to write an answer as a comment)

    @AnnonomusPerson every bit of documentation is available not only online, but offline as well. Just press f1 on QWebElement and you will get to section wich explains in detail every method and field of this class. In fact i've never seen anithing like this in any other framework. Usually you have to search docs on some godforsaken site and hope that docs even exists, when here, all input parameters, if they are qt types links to description of that class etc.Even if this is not enough, documentation for every major version available online at http://qt-project.org/doc/qt-4.8/qwebelement.html

    @AnnonomusPerson another point is that qt has a HUGE amount of examples already within qt. I'm sure that there are one with QWebElement. As i was sayng, i don't have expirience with QWebElement, post it on SO and it would be answered, but i could guess, that if QWebElement does not have means to change geometry itself, then the widget, that holds this element should have it, like QWebFrame or something. Just give it a time and look for an answer.

    @Shf I couldn't find any of that with Google, thanks for the link. But there's no examples, nor did anything install right; I had to add all compilers and redownload a ton of stuff to get it working: it may have been a bad install. I've tried it before and had it failed, so may have some corrupted files left over. BTW: MinGW was a pain to try to figure out to install too.

    The complaint about the non-native UI is irrelevant. A good designer will make a UI that is easy to use and intuitive, regardless. Qt's cross-platform functionality is probably the best there is.

    *"Qt is not a C++ library. It requires a separate compilation step"* - this is wrong, and a common misconception. Qt does not require a separate compilation step. It provides *pre-processing* tools as a *convenience* to generate boilerplate C++ code which you'd otherwise have to write manually. There's nothing to stop you writing that boilerplate code yourself, if you wish, and it's all standard C++.

    *"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."* - this is also wrong. Qt is available under GPL v3, LGPL v2 and a commercial license. Even with LGPL, you can still do single binary deployment (static linking) with relative ease, so long as you provide the means to your users to re-link at will (e.g. give them object files or source code). Qt itself can be difficult to link statically, but that is unrelated to licensing.

    @Jon: See my comment to Dehumanizer earlier in this long long series of comments. I believe it addresses that point. The commercial license is too restrictive for a lot of projects.

    @BillyONeal Ah ok. Nonetheless, the answer as it stands is still factually wrong ("It's available only under LGPL") and should probably be edited.

    @Jon Qt really does use a pre-processing step, namely the MOC (Meta Object Compiler) phase which **produces** code. For every C++ file defining a class declared as `Q_OBJECT`, it generates a corresponding moc_* file containing all the machinery to make the SIGNAL-SLOT plumbing work. This is not *boilerplate* code, and you cannot write it yourself. Similarly, it processes .ui files to produce code. Aside from that, Qt features underwhelming GUI performance, due to its decision to use a **software** rasterizer. A complex Qt GUI is usually extremely sluggish.

    A few more points worth noting: 1) GUI performance is abysmal. With the introduction of the software raster engine (Qt 4) the rendering performance plummeted, leading to extremely sluggish GUIs. 2) Qt generates source code, making source configuration management more involved (excluding additional files). 3) Qt binaries are compiler specific. You cannot move your Qt 4 project from VS 2008 to VS 2012, without recompiling the binaries. 4) Digia's support ain't. Getting Digia to fix a bug is hard. Getting Digia to fix a bug without introducing new ones is impossible.

    @Tim: RE: 3: Libraries that use C++ are compiler specific. You can't e.g. throw an exception from something compiled with one compiler to something compiled with another compiler. There's no reason to turn this into a bashing piece.

    @Billy That's true, C++ libraries are always specific to a particular compiler. The point I was trying to make here was, that Digia does not provide or support binaries for a wide range of compilers. You will not get Qt4 for VS 2012, for example. This leaves you to build Qt from source, so you have to install Ruby, Perl, and Python, and deal with the stubborn QMake system. Only to wind up with a platform that Digia will not support, even if you purchased a commercial license. This is something you have to consider when making the decision to use Qt or not.

    @Tim That's what I said, a pre-processing step. And you are wrong that you cannot write the code yourself. Anything which is C++ can be hand-written (with sufficient effort). You can even supply an entirely alternative system to replace slots and signals, etc. My point was not that you should write it, but merely that it is not a compilation step. So for example, for code which is never going to change, you could check your MOC'd code into source control so that future developers don't need the MOC tool, something you couldn't do if MOC were a compiler. The same applies to the UI tool.

    @Tim As for your point about binaries, that is hardly a criticism of Qt. There are a huge number of binaries available pre-built for Qt. Compare that to Boost, where there are no official binaries, and you must compile from source for every different platform/toolset that you require. I do however agree with you that Qt is relatively time consuming and tricky to compile under different configurations compared to many other libraries.

    How is #6 even a problem in 2014?.. My Qt-based app's installer weighs 4.5 MB, I call that small enough.

    @Violet: When you're adding a simple GUI for an existing 500Kb uncompressed console app, growing 8x in size for that simple GUI is unreasonable. There are still a lot of users on dial-up out there.

    @BillyONeal I know I'm many years too late to the party, but just wanted to add that stylesheets existed for QWidgets long before QML existed. For example, here's some old documentation for the QStyleSheet class from Qt 3.3 (released in 2004): https://doc.qt.io/archives/3.3/qstylesheet.html AFAIK it existed long before that too, though.

    Are you aware whether these points (specially#6) still valid in 2017?

    I wonder how relevant answer #6 is now days, where the alternative cross-platform UI solutions are all Javascript/web-based. The binary size of an Electron app, for example, completely dwarfs that of a Qt app in my experience.

    I'd go further than calling `moc` and `uic` "pre-processing step(s)". They are *compilers*. I did a count of how many different compile steps were involved in my Qt project, and *not counting* the platform specific C++ -> native binary compilers, I reached 6

    @S.M.Mousavi The comparison is with a plain desktop C++ app, not a .NET one.

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

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

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

    The space needed for Qt is cheap these days.

    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.

    from Qt 5.8 afterward there is a project named Qt Lite which minimises extremely Qt for your specific needs. this is a commercial feature ;)

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

    Out of interest, what do you see as the main problems with WX?

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

    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.

    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.

    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?

    **everything that responds to a signal has to be a Q_OBJECT,** No nowadays... Now, static functions, functions and even lambda functions can respond a signal (you can use function pointers as slots). No-QObject classes can also have member slots if you connect to them using a std::bind to convert the instance member to a function pointer.

    @EdwardStrange the property grid widget isn't in its official release now. Very bad news, one have to build it by themselves.

  • 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 Qt ITSELF 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.

    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.

    @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?

    @MarcusJ libui is exactly that (though without KDE support).

    I want to add that you can now use Qt/QML with .NET. You don't need to touch C++. https://github.com/qmlnet/qmlnet PS: I'm the author.

  • 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 if there is a shortage of other options. For instance WxWidgets, GTK+, and Tk are 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.

    Cool. I didn't know that GTK+ is a cross-platform. Is it really?

    @Dehumanizer: According to Wikipedia it is. But I don't know how well the non-X-Windows ports actually work.

    @btilly: GTK+ is cross platform. For example, the Pidgin IM client is written on GTK+.

    Ok, however, it is possible 'somehow' to run on Windows:)

    Just install GIMP on Windows and have a look.

    Yeah, and GIMP works well on Windows, but it certainly doesn't fit in with the Windows 7 UI look & feel.

    @Billy ONeal, @ammoQ: To test either of those on Windows I'd need to have access to Windows. Which I don't. That is why I limited myself to just repeating what Wikipedia said.

    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?

    It's funny that this question hasn't received more upvotes, given that it is really the only one actually addressing the real historical reason why "mainstream" desktop(=Windows) development did not adopt Qt. First the licensing was crap, and then, when the licensing finally caught up, people were already using .NET or were locked into their legacy MFC stuff.

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

    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 obviously if you know C++ very well and you don't Qt, you will not be more productive with the latter. But when you get to know both C++ and Qt, the framework is really making a lot of things easier and quicker to implement (C++11, 14 etc are filling the gap, but not fully yet).

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

    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.

    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

    I agree. Least worst. And even on Windows-only apps I'd rather debug QT issues than MFC issues.

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

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

    But Qt provides ability to write only console application. Isn't it?

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

    @Geret'kal: No, I'm looking for a reason. I agree with you at all, just want to find out the difference of other "similar" libraries.

    @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 library **when you don't have a use case** is a fool's errand.

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

    "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 :-)

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

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

  • 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!

License under CC-BY-SA with attribution


Content dated before 6/26/2020 9:53 AM