Qt itself has a few "graphical frameworks" to do the rendering.

QWidgets is what you're referring to. That's what is used to build traditional desktop applications and is rendered using software by default.

QML/QtQuick is their GPU accelerated scenegraph: https://doc.qt.io/qt-6/qtquick-index.html . It is mostly used in mobile/embedded systems, but they do have desktop components too.

> It is mostly used in mobile/embedded systems, but they do have desktop components too.

This is misleading. QML was supposed to be the successor of QWidgets. Many big apps use it just fine on the desktop. Sadly many Qt dev themselves (just look at the QtCreator code, do you see any commits using QML there?) do not like QML and so it never really replaced QWigets. Now we have a community that is essentially split and every party cries if one gets more updates then the other. QML still has things like TrayIcon support as a unstable labs preview module, after nearly 10 years. Yes I'm a full time Qt/QML developer and I'm salty about this :*)

For a desktop application widgets are better than QML. QML brings things to your UI that a desktop application shouldn't use. QML is the right way to do phone applications, but there are good user interface reasons to not use most of the features QML gives you on desktop applications, but to use those features on phone applications.

Not that you cannot build good desktop applications with QML, but there will be a lot more work for questionable gain.

Please give me a single reason what QWidgets does have that qml doesn't, from a user perspective.

> lot more work

I would argue the opposite. Show me a none buggy QWidgets application that features nested collapsing menus, with animations. That being said, you can still create a modern app with fancy animations in QWidgets. The beautiful Telegram QtWidgets desktop app is the best example, it's just more work....

That you cannot do those animations is a feature! Animations are useful in places, but they also make for hard to use user interfaces. Widgets where designed in a world where user interface experts sat real humans down behind on-way mirrors and watched how they used applications: those experts had long learned fancy animations look great but typically result in it being harder to use user interfaces.

Exactly, whenever I see an animation on my desktop I instantly loose 20% confidence in the app

I don't have a lot of experience with Qt but recently was exploring both QtWidgets and QtQuick as options for simple desktop UI.

QtWidgets made creating forms massively easier thanks to QFormLayout and drag and drop designer.

There was nothing similar in QtQuick - Grid and Qt Design Studio were absolutely horrible for this.

The point of QWidgets is not to create a "modern app with fancy animations", that's what QML is better suited for. It can still be done, QWidgets supports theming and all that, but that's not what it does best.

QWidgets is for making well integrated, "boring" desktop apps. For nested menus, or any menu for that matter, use QMenu. If your OS is fully supported by Qt and the standard system behavior is to animate the menu, it will be animated in your app.

I will say that the KDE system settings application uses QML for its sidebar and it behaves terribly when resizing the window (takes around a second to resolve the layout after resizing). I haven't seen the same behavior with QWidgets programs.

> Please give me a single reason what QWidgets does have that qml doesn't, from a user perspective.

QWidgets gives you widgets that look like they're desktop widgets, QML gives you a white rectangle.

This is false https://doc.qt.io/qt-6/qtquickcontrols-styles.html

That looks worse than widgets.

Why do you NEED animations though? That has never been an important feature for users.

"modern app with fancy animations" is not a good desktop app, is the point. You're assuming a requirement of things that people simply don't want.

>Sadly many Qt dev themselves...do not like QML and so it never really replaced QWigets

Says it all, doesn't it. I'm sure everyone's wrong and it's the un-liked framework that's correct, yes?

Does QML even have any system theme support? AFAIK its more of a replacement of web technologies than of QtWidgets.

Yes, nowadays QtQuick, the GUI library that is generally associated with the QML programming language, supports native styles: https://doc.qt.io/qt-6/qtquickcontrols-styles.html

Lacks a Microsoft Fluid style for Windows 11.

It's in the roadmap afaik, they talked about it during QtWS

I think in our modern age, a lot of people can be surprised at just how fast the CPU is relative to GPU. Slower, yes, but compiled SIMD-enabled CPU code is bloody fast. I've seen people on HN claiming "just put it on the GPU and be 10,000x faster"; I can only assume this comes from comparing interpreted Python code with compiled kernel code or something! Basic drawing code is highly likely to be memory-bandwidth-bound; Some napkin math shows e.g. a 4070 has about a 10x performance advantage over a Zen4 CPU (500gb/s vs 50).

Rant out of the way, obviously 10x faster is still an order of magnitude faster! I've continued to be curious if there's a way to properly batch geometry in the QT backend to remove all the state-changes that the QT painter is doing that kill performance; a powerfully GPU-accelerated backend for widget based apps would be incredibly useful, although given the dominance of web/electron apps these days not a useful feature for a commercial company to build.

There has been more and more “GPU chauvinism” over the past decade. For whatever reason many people have come to see the GPU architecture as the pinnacle of modern computing, seemingly unaware of its limitations. Although CPUs are boring in comparison, they most often don’t require special toolchains, shader languages, near and far memory, etc. Moreover, SIMD instruction sets like AVX-512 or SVE2 offer extremely impressive performance, often negating the need for a GPU altogether.

Of course this isn’t to be dismissive of GPUs, they are a welcome addition to the compute stack. But the humble CPU should not be underestimated.

We at https://lekh.app wrote our own tiny UI library in C++ to implement our canvas screen UI. Here is a screenshot https://i.imgur.com/gr1ernJ.png of the canvas screen. Lekh is a whiteboarding and diagramming app.

With a single codebase, we are running on iOS, Android and web. We do not have our own Rasterizer but we depend on the platform for that. We render in the main UI thread and performance wise we are fine on these three platforms.

What about text input? That's often where this kind of solution is lacking for more general-purpose use.

Does it support selection? Cut and paste? European languages? Chinese and Arabic? Hiding and showing the virtual keyboard as appropriate?

Text input is an exception. I mean, we used the platform text input instead of implementing our own. We have our own API for text input but under the hood it uses platform text input.

https://ossia.io uses widgets and qgraphicsscene for the main UI rendering and Qt rhi for the GPU pipeline, and it's performing well enough for our use-cases - I was working on it on a 1080p screen on a Pi4 recently and it certainly felt much much faster and responsive than chrome on the same hardware.

QT uses the GPL where it makes sense. However widgets on any platform mostly do not make sense to run on the GPU.