I might be a wee bit biased because I work with Qt, but seriously, its breadth, quality, and documentation are why it's the quasi-standard for cross-platform UI programming. There is currently a discussion about the ownership model (I guess that is meant with "ancient paradigms") on the development mailing list. The ownership model isn't really among the top n problems during typical development in any case. There is also QML which is an extremely productive way to create hardware accelerated touch-friendly UIs. QML is widely used in embedded systems.
This is going to be a very limited list though, for instance there are dozens of applications in my domain that use Qt, and none of them are on this list.
Don't know if it is big or not, but Andy Brice's Perfect Table Plan is made with C++ and Qt, and IIRC, it runs on both Windows and macOS. It's been around for a long time and sells fairly well, according to posts on his blog, successfulsoftware.net , which I have been reading for a while. The blog also has many good posts about desktop software product development and marketing. Also, he's pretty much a one-man show, except fr some things, which shows it can be done.
I found it quite amusing, specially as the author failed to present a case -- and an example -- of what he perceives as being a modern paradigm.
I mean, how many projects he listed that supported any kind of UI design tool?
To me, Qt is still leaps and bounds beyond any alternative, not only in is design-centric tooling but also ease of use. Doubly so with Qt Quick. I find it quite strange that those aspects of Qt aren't readily noticed by someone who bothers to produce a list of C++ UI toolkits
I fail to see the point of your complaint. Besides the fact that Qt's "pre-compiler" is used to transparently support stuff such as UI design tooling and Qt's resource system (which handles embedding images and i8n), Qt's meta-object system also adds the boilerplate code that implements stuff such as event loops, IPC, observers, and message-passing.
So, actually, what's your point?
This complaint is particularly absurd if we compare Qt with unquestionably modern technologies such as the Android stack, whose build process is jam-packed with precompiler steps and whose project trees are filled to the brim with XML-based DSLs.
> inheritance over templates, little use of the standard library
These complaints make absolutely no sense at all.
> need I say more?
...Yes? You actually failed to make a single point, let alone presented a rational argument to back your assertion.
> It is leaps and bounds beyond other things - but those leaps and bounds are into the past.
This jab is simply stupid, more so in light of your complains.
FWIW this is a plus :-P i prefer working with Qt's containers and strings than STL (not specific to Qt really, i prefer almost any other container, string, etc library than STL, the API of which i find very unintuitive). Qt isn't just a library really, it is a framework you build your application around, when you use it you are supposed to buy in everything it does.
- how do you implement reflection without either ugly macros or a precompiler?
- how do you implement metaclasses without a meraobject ? (e.g. how would you list all the methods or properties of a class)
- how do you implement a tree structure where the parents knows its children and the children know its parent in modern C++ (or Rust without unsafe :-)) ?
Didn't you know that declarative, binding-oriented, hardware-accelerated, scene-graph based GUIs are both based on ancient, completely outdated paradigms, and slow?
And even besides QML, stuff like QGraphicsScene isn't really what I would call slow for CPU-based 2D graphics. It's good enough to be the rendering system for e.g. ECAD design tools.
> feature creep, the project
> uses ancient paradigms
> tends to overtake all your structures
> slow
> I don’t like it
Seriously?...