Widgets vs. QML: Choose A Side — and Prepare to Lose Friends

Axel Spoerl

Last weekend an acquaintance from Vienna visited Oslo with his family.
Being a notorious Widgets fan, he made the bold statement that he can write a QWidget UI in plain C++ (i.e. without Widgets Designer) over a beer while watching a movie. I love Widgets. But I had to choose the other side and accept a challenge:
We would both write the same app: A desktop UI for Gerrit, that allows mass staging without having to open each commit in a separate browser window. I would write it in QML with C++ extensions. He would write it in Widgets. We both agreed on two common denominators:

A class that wraps the ssh interface to Gerrit
A class inheriting from QAbstractItemModel that eats Gerrit's JSON output (yes, after manually deciphering lines with JSON objects into a proper JSON array)

I will not say the name of my acquaintance, because he hasn't finished his application yet and I am not sure whether he ever will (if you read this, XXX, yes, I am looking at you!)

My part is here. It took me the larger part of last weekend and some evenings last week too. I am so bad at QML - without help from @shawnrutledge, @mhqanbari, @FKosmale and @Oliver-Eftevaag I couldn't even have displayed a ListView correctly. It is hackathon style, nothing to be particularly proud of. It does what it was meant to do. And it was a total fun exercise. My first QML application ever.

Because I am a Widgets guy. I love them. They do exactly what I want. I don't have to think about C++ extensions, because I am already in C++. I can use all the types I want directly, without hiding anything behind var. I don't have to wonder why displaying text in dark mode in a TextField looks broken and nice in a Label. And the fact that Noah used Widgets in his shipyard, make them a proven tool, solid as a rock.

QML separates design from the heavy lifting in C++. I get that. Let designers do their work in QML and C++ heroes write extensions for the complex business logic. The shift from a Widgets application to QML has made MuseScore my favorite tool for writing sheet music.

With that said: Which side do you pick? Are Widgets Swiss Army knives or dinosaurs? Is QML the future or a bad dream?
I know that my friends @JonB, @SGaist, @Christian-Ehrlicher and @Mike-Trahearn-0 have opinions.

JonB

I will be brief, since I have never used QML and hope I never have to. I'm sure it looks pretty and is fast. I don't get a how a programmer can use it for anything. It's lines & pages & files for what seems to me to be a small part of a decent application UI. To do anything like I would expect it would need tons of code behind, partly for extra UI functionality, but mostly backend. And then I have to tie that from QML to C++ or use script or javascript or something for any logic beyond the most basic functionality. UI is not my thing, so long as it is functional. I am interested in all the backend stuff :)

cristian-adam

The acquaintance should have used a local LLM, gpt-oss is doing wonders with Widgets. Maybe it can do wonders with QML too.

These LLMs know python by heart, so one could rapid prototype with Pyside6 and Widgets very fast...

SGaist

@cristian-adam said in Widgets vs. QML: Choose A Side — and Prepare to Lose Friends:

The acquaintance should have used a local LLM, gpt-oss is doing wonders with Widgets. Maybe it can do wonders with QML too.

These LLMs know python by heart, so one could rapid prototype with Pyside6 and Widgets very fast...

I am not going to make friends but: I think the whole point of that duel was to pick each other's brain doing something fun (the debate around Gerrit API being fun is another topic ^^) and learning something in the process. Involving an LLM would have just ruined the game. Or you put their use in the rules of the duel.

GrecKo

@JonB said in Widgets vs. QML: Choose A Side — and Prepare to Lose Friends:

I have never used QML and hope I never have to. [...] I don't get a how a programmer can use it for anything. It's lines & pages & files for what seems to me to be a small part of a decent application UI. To do anything like I would expect it would need tons of code behind, partly for extra UI functionality, but mostly backend.

Uh? Where does that even come from?

I've been writing c++ for 2 decades now, and i can even say that I like the language but I don't see why would someone willingly chose it to write UI. I keep it for things that matter, where I have to interface with outside system of for the business logic.

I'm used to QWidgets but I am very glad that QML surfaced. The language is way more suited for the job when you understand its declarative approach.

Customization on widgets is a pain, you either have to struggle through blood, sweat and tears dealing with custom painting or QStyle stuff or throw stuff at the QSS walls and hope it sticks and not look too out of place.

QML has the advantage of being easily composable and benefiting from property binding. It's pretty straight forward to generate a reusable component with custom properties. And when Qt Quick shows its limits I can still dive into c++ to extend it and hide the complexity away behind a nice declarative interface.

Axel Spoerl

I would have expected more fire at this debate!
When @Christian-Ehrlicher and I had been made QWidget maintainers (alongside Volker), one of my office maters said: Congrats. You're the only grandfather at the Oslo office. An obvious, natural choice.

Christian Ehrlicher

@Axel-Spoerl said in Widgets vs. QML: Choose A Side — and Prepare to Lose Friends:

I would have expected more fire at this debate!

I did not use qml so I can't say anything wrt this. And I doubt I will use it in the near future -interpreted languages are imho not very usable in the environments I'm working.

jeremy_k

@Axel-Spoerl said in Widgets vs. QML: Choose A Side — and Prepare to Lose Friends:

I would have expected more fire at this debate!

I didn't post earlier because it would have been nearly identical to @GrecKo's missive. There's not much call for fire. I use widgets if I want something that looks like a widget application, and requires no significant style changes for the platform. Otherwise, QML is easier to work with than .ui files, or imperative C++ and python. I'm holding out hope that one of the widgets in QML layout projects reach maturity.

@Christian-Ehrlicher said in Widgets vs. QML: Choose A Side — and Prepare to Lose Friends:

interpreted languages are imho not very usable in the environments I'm working.

What environment is that?

I find that inexperienced QML coders lean heavily on javascript. Better structured QML is more like .ui files, laying out elements and connecting signals to slots, but otherwise treading lightly on program logic.

SimonSchroeder

There used to be a case for consistency between applications. Did you know that IBM held a patent for the progress bar? Luckily for us they never enforced it. It would have been really bad for them because if just their apps had used progress bars they would have been the non-conforming ones. (At least, progress bars are easily understandable so that they would not have startled users.)

QWidgets provide a constistent interface for each (desktop) platform. It also provide only widgets that everybody knows. QML on the other hand is more like an interface to go crazy with design. Every app looks different (if you don't just use the basic design elements) and works slightly differently. It is easy for designers to make something beautiful that has terrible UX. I do understand the practicability of QML for large project teams that have dedicated designers. For a designer QML is the better choice because they don't have to learn C++. However, I mostly work on small projects with two or three C++ programmers. Non of these projects use QML because we don't have a designer at hand.

I do understand that QtC wants to make money and the money seems to be in automotive using QML. But, for hobby projects C++ programmers just need an easy interface. And honestly, QWidgets is the easier alternative to quickly put up a UI if you are a C++ programmer. I personally prefer to write QWidgets in C++ code and not using the Qt Designer (though my colleague is the opposite). Using the Designer needs a lot of work arounds when you want to rearrange widgets (and sometimes you get empty cells in grid layouts that you need to clean up). I find it a lot easier to just rearrange the lines for layout->addWidget(w);. Also, writing C++ gives a lot better overview which of the default parameters have been changed. I'd rather type on my keyboard than use the mouse (and my colleague is the exact opposite).

(Though the idea of the Designer is enticing: There are interesting videos on YouTube where Steve Jobs does something quite similar using his NextSTEP instead of Qt: Just clicking a few widgets and connecting their slots.)

I would wish, though, to have a more modern looking interface with QWidgets and to have things like transitions and animations similar to QML a lot easier. (Though, there's already QPropertyAnimation.)

EduardoQtDev

I am QML side, I do not remember the last time I used QWidgets.
I would say I can do whatever I want/think with QML.
It is a shame people still do not understand how one can produce cross-platform reusable GUI components with the mix of CMake, C++, and QML. The latter components can be plug and play in your application.
Also, QML is a declarative language that makes it cleaner than C++ for UI interfaces.
Now with tools like qmllint, it is quite easy to find errors before they happen at runtime.
QWidgets is C, and QML is C++ in the sense that if you want a fast thing done, you use QWidgets; if you want to design a reusable, nice-to-use interface, you use QML.

GrecKo

@SimonSchroeder said in Widgets vs. QML: Choose A Side — and Prepare to Lose Friends:

QWidgets provide a constistent interface for each (desktop) platform. It also provide only widgets that everybody knows. QML on the other hand is more like an interface to go crazy with design.

Qt Quick Controls have native styles now.