I've worked with QtWidgets and I have mixed feelings about the extensive (1) documentation about integrating C++ with QML and QtQuick.

Here's a quick history lesson (as I understand it):

- QtWidgets the original C++ QT graphics library.

- Around 2008 or something, they introduced QML and QtQuick. This was basically declarative UI + javascript for logic.

- QtWidgets is considered 'done' and all new features and dev is basically happening in QML / QtQuick.

- ...as described in this post, the current recommended 'best practice' is to avoid writing a pile of javascript spaghetti and bridge between C++ for logic and QML for UI.

So, long story short: We've moved from a robust C++ framework, to a javascript backed framework to 'appeal to the masses', but it's kind of hard to build a whole application that way, and so 'best practice' is to go back and write your logic in C++.

Does that seem weird to anyone else?

> While powerful, Qt Widgets lack some essential modern features, in my opinion, such as declarative UI, bindings, behaviors, anchors, and more. These features enable the creation of beautiful, animated UIs simply and quickly, as seen in QML.

Hum. QML is certainly declarative.

I'd love to see a breakdown of specifically what features you can't do with widgets, and why having a js <-> c++ bridge is better than not having one.

Don't get me wrong; if you want to write a 100% javascript QML application, that's cool. Go for it... but when you're writing a C++ application and choosing, deliberately, to implement you UI in another language and communicate with that UI via a bridge...

...well, let's just say, if you had another option (eg. just use C++), wouldn't that make sense?

Couldn't you do the the same thing with react native components and logic in C++? (You could) Why is this any better than just writing a react native UI? Or a flutter UI?

You could do any kind of UI, even fully native, if you're implementing the application is c++ and then just doing cross language <-> to the ui.

Right?

[1] - https://doc.qt.io/qt-6/qtqml-cppintegration-overview.html

What exactly - from an end user perspective - do you worry about? Performance? I already showed in my benchmarks that my block editor is faster than all block editors on the market - even more than those that uses native frameworks.

And as I wrote to another commenter: "if you avoid writing Javascript code in your QML components, than most of your executable will end up being compiled C++ code. If you do write Javascript code in your QML components, than it could also be compiled to C++ code using the QML script compiler[1[2]."

BTW, I agree that there's not enough good documentation about communicating and connecting C++ and QML code. I hope I could write some tutorials for that in the future as I struggled with that when first delving into this.

[1] https://doc.qt.io/qt-6/qtqml-qtquick-compiler-tech.html

[2] https://doc.qt.io/qt-6/qtqml-qml-script-compiler.html

Generally, QtWidgets is better suited for making traditional desktop UIs with dialog boxes, common controls, etc... It is not really in the spirit of QtWidgets to do things like custom behavior, animation, etc... You do whatever the host OS gives you, in fact, you don't even care, that's Qt's job.

QML is better suited for apps that want full control of their UIs, styling, etc... Which is a more modern way (doesn't mean better!).

It is clear that the author wants the latter, so QML it is.

And yes, it makes sense to use a different language for the UI in this case, with C++ bindings, C++ is not that great for designing UIs. In fact, with QtWidgets, you typically don't use C++ to design your UI. Instead, you use Qt Designer, a graphical tool that works on .ui files (xml), that are then compiled into C++ classes that your derive from, which is a form of binding between two languages: C++ and .ui/xml. You can use C++ directly, sometimes you have to, like when the UI is dynamically generated, but for something like a dialog box, using the graphical tool is much more convenient.

I used Qt back in the day, pre-Nokia, when it was just QtWidgets for cross-platform (Linux/Windows/Mac) desktop apps. I just wanted a decent C++ library/API to create the GUI for a Linux app (real-time spectrogram). It was a great for this, although I was never a fan of MOC - I wish they had committed to a pure/native C++ design.

For me Qt lost it's way when Trolltech was acquired by Nokia, and the focus became mobile rather than desktop, with different UI requirements resulting in QML/QtQuick being added.

Maybe the earlier addition of QtScript (or even MOC!) was a foreshadowing of what was to come, but in any case what had been a great cross-platform desktop UI toolkit, and the primary C++ one for Linux (with GTK being more C focused) ended up orphaning it's desktop roots to focus on mobile instead, having become a sprawling mish-mash of languages, GUI component technologies and scripting.

> Couldn't you do the the same thing with react native components and logic in C++? (You could) Why is this any better than just writing a react native UI? Or a flutter UI?

The tooling, that is why.

Having QtCreator, Qt Design Studio, compiling QML to native code, debugging experience.

React Native has all the gotchas from JavaScript and poor tooling for developers that never left the CLI world.

Flutter depends on Dart, a programming language that was rescued from oblivion thanks to Flutter, and is pretty much useless everywhere else.

As someone who doesn't do too much GUI programming on Linux, I find QML quite useful, actually.

Small effects and simple state switches ("disable/hide this group of inputs when the user disables the 'advanced' checkbox") can be written in simple code. The advanced plumbing (custom control rendering, window management) is left to native code.

There's a delicate balance there that I can imagine will be difficult to maintain long-term, but many applications just need a handful of buttons and maybe a text field somewhere to do their job, and that's where QML shines.