QGridLayout is my go-to for applications. I like how it allows a responsive design when resizing. Most of my desktop apps are for simplifying tasks that my coworkers and me are doing, so no one's expecting the most professional look and Qt has gotten the job done.
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.
Well, I don't want to bash on QML, since I really appreciate the efforts that the team puts in it. But I do think its current state is not the best when compared to Qt Widgets, and lament that there's a split between the two toolkits inside the framework. The problems I had with QML are:
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.
I can't speak for the author, but many systems programmers look at declarative/markup-based UI as a kind of black magic that you can't trust and that will get in your way sooner or later by not leaving a sane way for you to address some project requirement.
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.
Widgets imitate one of the native UI toolkits (Win32 CommonControls, macOS AppKit) and can be embedded within those, and native widgets (HWNDs/NSViews) can be embedded within QWidgets.
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.
Desktop and tablet/phone applications need very different UIs. Anyone who tries to force the same UI on both is wrong and needs to be forced back to human-machine-interaction school (odds are they never went in the first place)
Rust bridge with C++ is a solved problem; since they have the same calling semantics you can easily bind rust callbacks to your c++.
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).
I'm also interested. I've been a UI developer for a long time but I've only ever built websites (with a brief stint doing iOS work), so I have little-to-no knowledge about native desktop UI solutions. I'm aware of QT and imgui, but beyond that I'm not familiar with the landscape.
QML wasn't (at least in the Qt5 days) a good fit for traditional desktop style applications. It was nice for more multimedia touch screen stuff, but HTML5 in an embedded browser like CEF or Electron was catching up fast and with much better third party library support.
That's actually a great idea for a second follow up article. I've worked a lot with rich text and custom text objects, but would also like to explore itemization and the lower level layers.
Managing widget size and layout in complex UIs is definitely one of the more challenging aspects of programming with Qt. But you usually get what you want with a bit of trial and error.
I am running up against it now. While QT works on the major OSes, it somehow manages to not quite fit with the design of the OS - which drives me crazy. If I wanted it to sort of behave like a Windows app, I'd write Windows apps. Sadly, it's the best option for Python.
Qt has a chronic problem with High DPI displays, especially when mixed with a lower DPI display in a multiple monitor situation. You will never get it 100% right and when you start shipping it to users that percentage will fall quickly.
magicmicah85|1 year ago
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.
Joel_Mckay|1 year ago
Personally, I was keen on Qt right up to the 5.x change over. =3
throwup238|1 year ago
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.
felipefar|1 year ago
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.
swatcoder|1 year ago
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.
Longhanks|1 year ago
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.
bluGill|1 year ago
wokwokwok|1 year ago
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).
danielvaughn|1 year ago
jdboyd|1 year ago
chris_wot|1 year ago
felipefar|1 year ago
What would you like to know more about it?
hermitcrab|1 year ago
drivingmenuts|1 year ago
joezydeco|1 year ago
ramesh31|1 year ago
01HNNWZ0MV43FF|1 year ago