Understanding the Layout Process in Qt Widgets
felipefarinon.com
Understanding the Layout Process in Qt Widgets
1–10 of 47 posts
Re: Understanding the Layout Process in Qt Widgets
#2I'm curious why you chose Qt Widgets for a relatively new application? Is desktop support that much better than QML?
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.
Re: Understanding the Layout Process in Qt Widgets
#3I'm curious why you chose Qt Widgets for a relatively new application? Is desktop support that much better than QML? 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.
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.
Re: Understanding the Layout Process in Qt Widgets
#4I'm curious why you chose Qt Widgets for a relatively new application? Is desktop support that much better than QML? 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.
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.
Re: Understanding the Layout Process in Qt Widgets
#5I'm curious why you chose Qt Widgets for a relatively new application? Is desktop support that much better than QML? 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.
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.
Re: Understanding the Layout Process in Qt Widgets
#6I'm curious why you chose Qt Widgets for a relatively new application? Is desktop support that much better than QML? 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.
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,…
Thanks for the detailed response! I'm definitely feeling the majority of these paint points.
> 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.
Re: Understanding the Layout Process in Qt Widgets
#7I'm curious why you chose Qt Widgets for a relatively new application? Is desktop support that much better than QML? 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.
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.
Re: Understanding the Layout Process in Qt Widgets
#8Earlier quoted context omitted.
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,…
Thanks for the detailed response! I'm definitely feeling the majority of these paint points. > 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…
> 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.
There's two things to consider when comparing rendering performance: throughput and latency. Throughput, or how much FPS the engine can sustain, is much better in QML since it's leveraging the GPU, but latency it's very platform-dependent. Mac is actually the one where QML does best in terms of latency (and by that I believe it approaches the latency of Qt Widgets), since it's synchronizing with the VBlank signal provided by CVDisplayLink. On Windows and Android the situation is worse.
Re: Understanding the Layout Process in Qt Widgets
#9Earlier quoted context omitted.
Thanks for the detailed response! I'm definitely feeling the majority of these paint points. > 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…
> 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. There's two things to consider when comparing rendering performance: throughput and latency. Throughput, or how much FPS the engine can sustain, is much better in QML since it's leveraging the GPU, but latency it's very platf…
Sidenote: Have you seen the new TextEdit improvements in Qt 6.7? I'm curious if that bridges the gap that you had when you started working on your app. My app is also text editing heavy so I'm hoping it's a big improvement.
Re: Understanding the Layout Process in Qt Widgets
#10I'm curious why you chose Qt Widgets for a relatively new application? Is desktop support that much better than QML? 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.
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,…
I recommend checking out Qt design studio. Once you get the flow on there, it creates a nice clean separation between the UI and backend.
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++.