Glad to see the update. Most people associate Qt with GUIs which is unfortunate.
I see that when people think of Qt, they think of WxWidgets, Cocoa or MFC as alternatives. No, I submit to you that Qt framework is a more elegant, easier to use alternative to Boost as well.
This is not to say that QtQuick or QtWidgets aren't solid. However, the success of these two modules ends up occluding the others which to me are the real gems from the QtFramework: QtCore and QtNetwork.
QtCore provides a solid event loop, the most easy to use implementation of the observer pattern via its signal-slot mechanism, robust threading utilities and a bunch of other utilities that make writing apps in C++ an absolute breeze.
QtNetwork for a series of networking utilities that are elegantly simple.
If I were to write a command line app or a database or server, I'd reach for Qt in a jiffy.
Qt is not just for GUIs!
I've coded desktop apps (mostly editors and tools for games) for 25 years across X (Motif toolkit), Amiga, TOS, DOS, MFC, Cocoa, Win32, WxWidgets, Fox Toolkit and Qt. Qt has by far been the best, most rewarding, most empowering experience. It's a great library.
Now Cocoa would win but I prefer C/C++ to Objective-C, it's close though.
Good work people.
I'm an indie dev and have been developing a cross-platform (Py)Qt app for the past 1.5 years (~2100 dev hrs) . Given that Qt is cross-platform desktop development, it's very solid. But there are a lot of things one has to do that are not required for (say) web apps:
* Creating standalone executables / installers for the app itself is already not so easy (I use - and recommend - PyInstaller ).
* Code signing the executables so users don't get an ugly "this app is untrusted" warning is tedious for the three different platforms
* Auto-updating is a pain to implement as well. I'm using Google Omaha (same as Chrome) on Windows , Sparkle on Mac  and Debian packages / fpm on Linux . In total, I probably spent two to three months just on auto-update functionality.
* You really can tell that Qt is "drawing pixels on screen". Sometimes you have to draw pixels / perform pixel calculations yourself. The built-in "CSS" engine QSS works to some extent, but often has unpredictable results and weird edge cases.
I considered Electron as well. But its startup performance is just prohibitive. I blogged about this (and which other technologies I considered) .
I've been wondering for a while whether I should not open source my solutions to all of the above problems, to save other people the months required getting everything to work. Would anybody be interested in that? It would be something like a PyQt alternative for Electron.
 People are very interested so I'm starting a MailChimp list. If you want to know if/when I open source a solution then please subscribe at http://eepurl.com/ddgpnf.
As good as QT and KDE are, I cannot really explain the fact that the most popular Linux distributions seem to show preference for Gnome; is Gnome more stable? is the user experience provided by Gnome more "polished"? or, is it the K-isms that push them away? is Gnome less resource-hungry?
Andy Brice has two successful desktop app products, Perfect Table Plan and HyperPlan , and both are written using C++ and Qt, IIRC; I read that on his blog , which I have been following for some time now. Lots of good info about product development and marketing there.
 At least, Perfect Table Plan is quite successful, he has been selling it for a long time now. HyperPlan is newer, but IIRC he had some sales for it too.
Is Qt a good, modern framework for desktop application development for a beginner? If not, can someone recommend something else?
This is awesome. I can't wait for the KDE binding generator to mature so we can finally start using it more properly from Rust.
I enjoy using QML together with Python 3 for the logic, with the PyOtherSide plugin: https://thp.io/2011/pyotherside/
Is Qt 5.10 still stuck in the time prior to C++11? Does it have clear pointer ownership and move semantics?
Qt used to be an absolutely awesome C++ framework. Then Nokia happened, and it turned into a weird Rapid Development Environment™ for Symbian®©.
Does anyone have up-to-date experience with Qt? It's quite clear Symbian is no longer the main target, but did they ever get back to treating C++ as a first-class citizen, or is it still all about QML?
November 2017: item?id=15617359
>pknopf: This reminds me of the project I am currently working on.
Not quite production yet, but it will be soon. I'd love to he[ar] some input. You can check the unit tests for how things are working currently.
Haven't used QT in a long time.Have they done away the with ’moc' and code generation? I found it extremely annoying that while we were using QT we weren't actually using c++, but a strange, language that looked like c++, but was actually further processed by qt to generate the c++ code. Are they done with that shebang?
This is also an interesting project, if you want to use Qt with Rust:
BTW, if you like both QML and Common Lisp, and want to reach for android, there's news: EQL5-Android https://gitlab.com/eql/EQL5-Android
Annoying thing with QT, the official pronunciation sounds like ’cute’, and some interviewers insist on calling it that.
Awesome cant wait to check out the new features!
The features of the C language were added with purpose. They were intended to solve a real problem and solve that problem they did. Simple arithmetic with promotion. Automatic register allocation with a portable (between compilers) ABI. A simple-but-handy preprocessor. And so on. C is also a lean language: a single person can feasibly write a C compiler in a relatively short time (tinycc is a C99-compliant C compiler written in just 65kLOC of C!). C set out to achieve a clear goal and it achieved its goal. Thanks to the cleanness of C lots of quality compilers came on the market quickly and even decent OSS solutions were available early on.
In contrast, C++ never had a clear goal. The features of C++ were added almost at random. Stroustrup's original idea was essentially "C is cool and OOP is cool so let's bolt OOP onto C". Retrospectively, OOP was massively overhyped and is the wrong tool for the job for most of the people most of the time. Half of the GoF design patterns just emulate idioms from functional programming. Real OOP languages like Smalltalk and IO express many useful things that C++ cannot. The feature that C needed most was perhaps parametric polymorphism (aka generics in Java and C#, first seen in ML in the late 1970s) but instead of that C++ got templates that weren't designed to solve any particular problem but rather to kind of solve several completely unrelated problems (e.g. generics and metaprogramming). Someone actually discovered by accident that C++ templates are Turing complete and they wrote and published a program that computed prime numbers at compile time. Wow. A remarkable observation that led to decades of template abuse where people used templates to solve problems much better solved by other pre-existing solutions such Lisp macros and ML polymorphism. Worse, this abuse led to even more language features being piled on top, like template partial specialization.
The massive incidental complexity in C++ made it almost impossible to write a working compiler. For example, it remains extremely difficult to write a parser for the C++ language. The syntax also has horrible aspects like List<Set<int>> being interpreted as logical shift right. None of the original C++ compilers were reliable. During my PhD in 2000-2004 I was still stumbling upon dozens of bugs in C++ compilers from GNU, Intel and SGI. Only after two decades did we start to see solid C++ compilers (by which time C++ was in decline in industry due to Java and C#).
C++ is said to be fast but the reality is that C++ is essentially only fast when you write C-like code and even then it is only fast for certain kinds of programs. Due to the "you don't pay for what you don't use" attitude, C++ is generally inefficient. RAII injects lots of unnecessary function calls at the end of scope, sometimes even expensive virtual calls. These calls often require data that would otherwise be dead so the data are kept alive, increasing register pressure and spilling and decreasing performance. The C++ exception mechanism is very inefficient (~6x slower than OCaml) because it unwinds the stack frame by frame calling destructors rather than long jumping. Allocation with new and delete is slow compared to a modern garbage collector so people are encouraged to use STL collections but these pre-allocate huge blocks of memory in comparison so you've lost the memory-efficiency of C and then you are advised to write your own STL allocator which is no better than using C in the first place. One of the main long-standing advantages of C over modern languages is the unpredictable latency incurred by garbage collectors. C++ offers the worst of both worlds by not having a garbage collector (making it impossible to leverage useful concepts like purely functional data structures properly) but it encourages all destructors to avalanche so you get unbounded pause times (worse than any production GC). Although templates are abused for metaprogramming they are very poor at it and C++ has no real support for metaprogramming. For example, you cannot write an efficient portable regular expression library in C++ because there is no way to do run-time code generation and compilation as you can in Java, C# and languages dating back to Lisp (1960). So while Java and C# have had regular expressions in their standard libraries for well over 10 years, C++ only just got them and they are slow.
C++ is so complicated that even world experts make rookie mistakes with it. Herb Sutter works for Microsoft and sits on the C++ standards committee where he influences the future of C++. In a lecture he gave his favorite 10-line C++ program, a thread-safe object cache. Someone pointed out that it leaks memory (Herb Sutter's favorite C++ 10-liner has a memory management bug).
My personal feeling is that the new Rust programming language is what C++ should have been. It has useful known features like generics, discriminated unions and pattern matching and useful new features like memory safety without garbage collection.