Timeline for Why aren't more desktop apps written with Qt?
Current License: CC BY-SA 4.0
71 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 15, 2021 at 8:14 | comment | added | asmmo | I think this answer is very unrelated to the current qt | |
| Feb 20, 2021 at 18:57 | history | edited | NecroMancer | CC BY-SA 4.0 | typo(ol' to old) |
| Jan 3, 2021 at 21:02 | history | edited | edition | CC BY-SA 4.0 | Clarified point 2 and 5 |
| Mar 1, 2019 at 20:02 | comment | added | Billy ONeal | @S.M.Mousavi The comparison is with a plain desktop C++ app, not a .NET one. | |
| Dec 19, 2018 at 10:04 | comment | added | Caleth | 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 | |
| Mar 9, 2018 at 0:03 | comment | added | dkaranovich | 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. | |
| Dec 22, 2017 at 13:33 | comment | added | PRIME | Are you aware whether these points (specially#6) still valid in 2017? | |
| Jun 23, 2016 at 9:55 | comment | added | user31753 | @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): doc.qt.io/archives/3.3/qstylesheet.html AFAIK it existed long before that too, though. | |
| Jun 5, 2014 at 17:09 | comment | added | Billy ONeal | @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. | |
| Jun 5, 2014 at 7:14 | comment | added | Violet Giraffe | How is #6 even a problem in 2014?.. My Qt-based app's installer weighs 4.5 MB, I call that small enough. | |
| Apr 26, 2014 at 20:09 | comment | added | Jon Bentley | @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. | |
| Apr 26, 2014 at 20:05 | comment | added | Jon Bentley | @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. | |
| Apr 26, 2014 at 8:25 | comment | added | Tim | @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. | |
| Apr 26, 2014 at 3:24 | comment | added | Billy ONeal | @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. | |
| Apr 25, 2014 at 22:51 | comment | added | Tim | 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. | |
| Apr 25, 2014 at 22:19 | comment | added | Tim | @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. | |
| Mar 4, 2014 at 21:38 | comment | added | Jon Bentley | @BillyONeal Ah ok. Nonetheless, the answer as it stands is still factually wrong ("It's available only under LGPL") and should probably be edited. | |
| Mar 4, 2014 at 21:08 | comment | added | Billy ONeal | @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. | |
| Mar 4, 2014 at 11:01 | comment | added | Jon Bentley | "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. | |
| Mar 4, 2014 at 10:57 | comment | added | Jon Bentley | "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++. | |
| Jan 30, 2014 at 4:17 | comment | added | trusktr | 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. | |
| Nov 1, 2013 at 20:31 | comment | added | Anonymous Penguin | @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. | |
| Nov 1, 2013 at 7:52 | comment | added | Shf | @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. | |
| Nov 1, 2013 at 7:46 | comment | added | Shf | @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 qt-project.org/doc/qt-4.8/qwebelement.html | |
| Oct 31, 2013 at 22:51 | comment | added | Billy ONeal | @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) | |
| Oct 31, 2013 at 21:02 | comment | added | Anonymous Penguin | @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. | |
| Oct 31, 2013 at 7:32 | comment | added | Shf | @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++). | |
| Oct 30, 2013 at 21:26 | comment | added | Anonymous Penguin | @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. | |
| Oct 30, 2013 at 15:27 | comment | added | Shf | @AnnonomusPerson you've got to be kidding, right? Qt is anything but poorly documented. | |
| Sep 18, 2013 at 6:53 | history | made wiki | Post Made Community Wiki by user102518 | ||
| Aug 17, 2013 at 22:22 | comment | added | Billy ONeal | @ПетърПетров: 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. | |
| Aug 17, 2013 at 20:30 | comment | added | PeterSvP | 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. | |
| Mar 18, 2013 at 18:27 | comment | added | Billy ONeal | @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. | |
| Mar 18, 2013 at 18:26 | comment | added | Billy ONeal | @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. | |
| Mar 18, 2013 at 18:05 | comment | added | annoying_squid | @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. | |
| Feb 7, 2013 at 23:09 | comment | added | Qix - MONICA WAS MISTREATED | Ah, this explained it. I've never overridden QObject. | |
| Feb 7, 2013 at 17:42 | comment | added | Billy ONeal | @Qix: You've never had to use moc? That is a preprocessor. | |
| Feb 7, 2013 at 7:26 | comment | added | Qix - MONICA WAS MISTREATED | 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... | |
| Nov 20, 2012 at 21:13 | comment | added | Billy ONeal | @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. | |
| Nov 20, 2012 at 20:25 | comment | added | Brian Knoblauch | OP: Bash away, you certainly wouldn't be the only one that's not a big fan of Qt... :-) | |
| Nov 20, 2012 at 19:56 | history | edited | kevin cline | CC BY-SA 3.0 | edited body |
| Sep 25, 2012 at 1:17 | comment | added | Billy ONeal | @SteveFallows: If I do that markdown just converts it back to 1. :) (It gets emitted as an <ol>) | |
| Sep 25, 2012 at 0:15 | comment | added | Steve Fallows | @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 :). | |
| Sep 24, 2012 at 20:45 | comment | added | Billy ONeal | By popular demand, I have made my #1 item the previous #6 item./ | |
| Sep 24, 2012 at 20:45 | history | edited | Billy ONeal | CC BY-SA 3.0 | added 2 characters in body |
| Dec 14, 2011 at 11:46 | comment | added | Kamil Klimek | @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" | |
| Dec 14, 2011 at 11:42 | comment | added | Kamil Klimek | @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". | |
| Oct 19, 2011 at 19:03 | comment | added | user8709 | @Billy - hence the ";-) but ...". | |
| Oct 19, 2011 at 14:43 | comment | added | Billy ONeal | @Steve314: That's the C preprocessor. It's still C. You don't need to modify your build system for that. | |
| Oct 19, 2011 at 13:32 | comment | added | user8709 | @Billy - ;-) but wxWidgets does use preprocessing - event tables are constructed using macros and other preprocesser stuff. | |
| Oct 14, 2011 at 17:05 | comment | added | Billy ONeal | @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. | |
| Oct 14, 2011 at 17:03 | comment | added | Trevor Boyd Smith | @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. | |
| Oct 14, 2011 at 17:00 | comment | added | Trevor Boyd Smith | @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. | |
| Oct 14, 2011 at 16:57 | comment | added | Billy ONeal | @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. | |
| Oct 14, 2011 at 16:55 | comment | added | Billy ONeal | @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. | |
| Jul 4, 2011 at 6:25 | vote | accept | Dehumanizer | ||
| Jul 1, 2011 at 17:26 | comment | added | Billy ONeal | @gbjbaanb: I guess we can agree to disagree on that point. | |
| Jul 1, 2011 at 17:24 | comment | added | Chance | @Crazy, you may be right, I see a Windows Installer, but I'm not familiar with VS and all that. | |
| Jul 1, 2011 at 17:04 | comment | added | Edward Strange | @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. | |
| Jul 1, 2011 at 15:52 | comment | added | Chance | Good points, but I disagree with #3. You can download a .bin file from Qt's website and not compile the source. | |
| Jul 1, 2011 at 9:45 | comment | added | Billy ONeal | @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. | |
| Jul 1, 2011 at 9:19 | comment | added | gbjbaanb | 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. | |
| Jul 1, 2011 at 9:07 | comment | added | Cody Gray | 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. | |
| Jul 1, 2011 at 7:24 | comment | added | Greg Jackson | #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). | |
| Jul 1, 2011 at 6:50 | comment | added | Billy ONeal | @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) | |
| Jul 1, 2011 at 6:44 | comment | added | Billy ONeal | @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. | |
| Jul 1, 2011 at 6:44 | comment | added | Daniel Lubarov | Great answer. 3 and 5 are the biggest concerns for me -- building takes forever on my poor laptop! | |
| Jul 1, 2011 at 6:42 | comment | added | Dehumanizer | Ok, understand. Do you know how much the commercial license costs?(It is very interesting to me:) | |
| Jul 1, 2011 at 6:37 | comment | added | Billy ONeal | @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. | |
| Jul 1, 2011 at 6:34 | comment | added | Dehumanizer | I see, but isn't Qt dual-licensed? | |
| Jul 1, 2011 at 6:29 | history | answered | Billy ONeal | CC BY-SA 3.0 |