[HN Gopher] Understanding the Layout Process in Qt Widgets
___________________________________________________________________
Understanding the Layout Process in Qt Widgets
Author : felipefar
Score : 28 points
Date : 2024-09-05 18:44 UTC (1 days ago)
(HTM) web link (felipefarinon.com)
(TXT) w3m dump (felipefarinon.com)
| throwup238 wrote:
| I'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.
| danielvaughn wrote:
| 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.
| swatcoder wrote:
| 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.
| hermitcrab wrote:
| Amen. I've coding in Qt since v1.x and have never felt the
| need to switch to QML.
| felipefar wrote:
| 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.
| throwup238 wrote:
| 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.
| felipefar wrote:
| > 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.
| throwup238 wrote:
| 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.
| felipefar wrote:
| I saw them, they are a very small step in what I believe
| is the right direction, since you can use a custom
| textDocument. Anyway what I think would be useful is to
| jailbreak the QML API. Make the QML C++ API publicly
| available. Let us derive from the controls, manipulate
| and customize them with C++, as the Qt team devs
| themselves do.
| stroupwaffle wrote:
| 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++.
| Longhanks wrote:
| 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.
| bluGill wrote:
| 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)
| hermitcrab wrote:
| 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.
| ramesh31 wrote:
| This is my stock response when anyone complains about CSS;
| consider the alternatives.
| 01HNNWZ0MV43FF wrote:
| I found Qt way easier around 2010, maybe the new flexbox
| stuff is good though?
| layer8 wrote:
| With CSS you typically need a _lot_ of trial and error, and
| then there's different browser implementations and versions
| on top of that.
| hermitcrab wrote:
| I prefer Qt layout to CSS any day.
| drivingmenuts wrote:
| 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.
| hermitcrab wrote:
| I think Qt looks and feels pretty native on Windows. It
| doesn't look quite as native on Mac, but it's not far off.
___________________________________________________________________
(page generated 2024-09-06 23:00 UTC)