Have you used Qt Creator? Once I started using this, my app development started flying because I didn't have to edit, run program, edit again. Just drag and drop widgets around, its very nice.
Personally, I was keen on Qt right up to the 5.x change over. =3
There's a bunch of tradeoffs for everyone who has to make that choice and it's always interesting to know why people choose the one that they do.
1) The controls that Qt Quick 2 provides are oriented toward touch interfaces, and some are not even feature-complete. For example, QML's Flickable on desktop can be scrolled by clicking and moving the mouse, a behavior that is clearly an artifact from the touch implementation. QML's TextEdit doesn't support much that QTextEdit does, which was particularly important for implementing an app that offers advanced text editing. Ironically, even though Qt Quick is touch-centric, Qt has lots of bugs on mobile platforms, and has a history of presenting regressions on those platforms.
2) Communication between QML and C++ is finicky. You have to use macros and Qt-specific constructs (Q_PROPERTY, signals, slots) to bridge both worlds. Qt Widgets doesn't need bridging in the first place, since it's C++ all the way down.
3) Control customization is a pain. In Qt Widgets, we can create a class that inherits from a standard widget, and then we can customize it however we want while inhering the behavior from the base control. In QML, you have to resort to javascript for that, which has different tooling and ecosystem than C++. Besides, C++ programmers find javascript dynamic typing more error-prone than static typing.
4) The latency of interfaces built with QML is higher than the ones built with Widgets. QML's rendering engine is lagging behind in the input latency mitigation front when compared to browsers, although they've been making efforts in this area.
I don't think those problems are unsolvable, and historically Qt has evolved a lot, so I hope they eventually tackle these issues seriously.
> 2) Communication between QML and C++ is finicky. You have to use macros and Qt-specific constructs (Q_PROPERTY, signals, slots) to bridge both worlds. Qt Widgets doesn't need bridging in the first place, since it's C++ all the way down.
This hurts so bad. I'm actually implementing in Rust so I've got double the pain and any Rust type is either a QVariant or *mut pointer but integrating with Serde to easily (de)serialize JS objects has mitigated some of the pain points.
> 4) The latency of interfaces built with QML is higher than the ones built with Widgets. QML's rendering engine is lagging behind in the input latency mitigation front when compared to browsers, although they've been making efforts in this area.
This one is surprising. I've had more problems with Widgets, especially when doing a lot of animations (even just scrolling big text views) on a 4K display on MacOS, but maybe I'm thinking graphics and not input lag. The software rasterizer/GPU pipeline seems to get overloaded on Mac (Great article on the rendering pipeline btw!)
The big thing that sold me on QML over Widgets - other than the latter being the redheaded step child by this point - was implementing hot reloading. Having the entire UI completely refresh when changing the QML is definitely a nice coming from browser frontend, especially given Rust compile times.
This should be fixed in Qt 6.9: https://bugreports.qt.io/browse/QTBUG-97111
> Ironically, even though Qt Quick is touch-centric, Qt has lots of bugs on mobile platforms, and has a history of presenting regressions on those platforms.
That's interesting. I'm soon planning on porting my app to mobile using QML so I'm curious how that would go.
> QML's TextEdit doesn't support much that QTextEdit does, which was particularly important for implementing an app that offers advanced text editing. Ironically, even though Qt Quick is touch-centric
I think the latest changes that expose textDocument and others are very good improvements[1]. Even without these, I managed to write my own advanced block editor using QML[2]. It took around 5 months but it was well worth it and quite straightforward to implement.
> The latency of interfaces built with QML is higher than the ones built with Widgets. QML's rendering engine is lagging behind in the input latency mitigation front when compared to browsers, although they've been making efforts in this area.
When you speak on input latency, what do you mean? For text? I really don't see much of a difference (at least here on my Mac). I saw you wrote that on Windows and Android it's worse. On Windows I didn't see an issue nor did someone reported about it.
[1] https://www.qt.io/blog/text-editing-improvements-in-qt-quick
While it may seem like Qt Quick is designed for touch primarily, it is not actually the case. Modern UI/UX design is a bit more abstract, and requires a bit more skill to get working.
My recommendation is to be patient, and work with Qt Quick it will pay off in the end (e.g porting the app to Android, etc). Focus on the UI/UX completely separately from the backend. And once that is established, the models can be developed in C++.
We/they are often way more comfortable working with the kind of programmatic widget and graphics library that we/they might write, and whose behavior we can debug and trace with our usual tools, then somebody else's weird new declarative/markup syntax that obscures what's actually going on behind the scenes and frustrates our tooling and workflow.
And this instinct traces back many decades, for as long as visual RAD tools and declarative UI syntaxes first started being introduced by big vendors.
This exact scenario has played out for many trying to adopt SwiftUI. For even moderately complex projects it’s common to get 90% of the way there fairly easily, only for that last 10% to be a struggle/slog as a result of its inflexibility. AppKit/UIKit may not be trendy or sexy and might take longer to get new projects spun up with, but it’s much more rare to hit that brick wall with them; you’ll probably be able to accomplish what you need with little or no pain.
I’ve seen shades of this in Jetpack Compose too, which makes me think that these sorts of problems are just inherent to the type of UI framework.
QML is a strange GPU canvas world that looks mostly alien and behaves just so slightly more different that it is immediately noticeable and annoying.
JavaScript-Rust bridging (or any managed language) is slower and more effort to explicitly design.
My $0.02 would be: with widgets you can implement a lot of complex backend logic in rust, using a package manager that works (ie. cargo) to get significant productivity gains from the rust ecosystem for implementing the logic of your application. Specifically for example, threaded processes, network interactions and file parsers / exporters which get you “for free” functionality for eg. Loading .vox or .fbx files in an app, then passing them to c++ for processing / editing / rendering in the ui.
With QML you’d have to do that by hand. What a meaningless chore.
Also with QML, the runtime is not node compatible, so forget using existing packages in that ecosystem to help.
(There are obviously downsides too, like rust for mobile, but for desktop applications rust static builds are trivial to bundle in the c++ build process using cmake).
What would you like to know more about it?
I've looked at the LibreOffice text layout algorithm, so I'm curious how Qt handle text layout!
Source: I develop a QT widget app and develop on a workstation with mixed high and low DPI monitors.
