QML is not "magic". It's a separate language that integrates with C++ and makes UI design easier, sort of like how webpages use HTML/CSS for the graphics and JS for the logic.
Magic can be de-obfuscated with documentation but if I can accomplish the same thing in C++ with nearly the same amount of code, then the magic isn’t for me and C++ is a lot more clear and reduces cognitive overhead.
That's not the case when it comes to QML/QtQuick though. It sounds like you were writing a desktop application, So C++/QWidgets were probably a better choice for your use case. But for embedded/mobile use cases, where reactive, smooth animated user interfaces are the norm, QML is on an entirely different league.
Also, with QML I didn't have to worry about the ugly combination of junior engineers and C++ footguns.
and the guy who sucks at C++ breaks things less
Our journey was like: "Wow.. this is so nice and easy.".. 70% later.. "Should have researched this better. Now we have to mix QWidgets with QML code to get what we want".
> The point is to keep my code in C++ and not hop around to x different files to make sense of my application.
Another point of view that differs from this is - QML lets you easily separate UI logic from business logic, to better make sense of your application. Especially when it comes to "responsive applications". For eg. All the UI related parts of your application stay in QML files in folders like desktop/ android/ common/ etc... All the "backend logic" stays in C++, ready to be used by all these UI elements.
It is not about being forced to write JS. Nothing stopping you from writing very declarative looking C++ either (fun article: https://woboq.com/blog/property-bindings-in-cpp.html ). It is just about using a better tool for the job. State machines. Reactive properties. Declarative UI description. All of these make you need a lot less code than writing everything in imperative c++.
Not sure what you are getting at with the "ideas are obfuscated to call it something else". You'd have a widget tree/graph even with QWidgets/QObjects. Would you call any QWidget program that uses QJsEngine "a browser stack"?. QML is just a declarative programming language, that lets you script QObject properties/react to signals/property changes.
NumberInput { id: width }
NumberInput { id: height }
Label {
text: "Area value is: " + width.value * height.value // automatically gets updated
}
QtQuick is a scenegraph that uses QML to render a GPU accelerated UI. Which is what is needed on embedded/mobile UIs to get smooth high performant animated GUIs. That'd be too ineffecient and cumbersome to accomplish with QWidget/C++.
> To accomplish the same in pure C++, you'd need to implement some kind of observer pattern/manually connect signals and slots across objects to allow for updates of dependent values (Label's text).
I do not find that extra work because it’s represented in the class itself and the observer pattern maintains my preferences.
Perhaps these technologies are useful for those who want to quickly write a mobile app with slick animations. Indeed it is a easy way for Qt to gain audience for those types of apps especially for people who aren’t able to learn C++. For my intentions I am looking for less overhead overall to keep files as pure C++ as possible to ensure that a class I’m writing represents the full scope of it’s functionality and domain.
In that post, I was just drawing a parallel to try and compare QML with some other better known technology. My point was not to say that it is actually HTML that goes into the program. I'm sorry if it caused confusion. My message was meant as a bird's eye technology comparison, ignoring the fine details.
A different, more to the point take is: just like a web browser reads HTML and ends up interpreting a visual representation of a page, the QML engine will read a QML file and end up with a hardware-accelerated visualization of it.
Qt just gives you the tools for that.
If you don't need a hardware-accelerated rendering of a UI, working smoothly at 60fps in consumer devices, then probably QML wouldn't bring much to the table anyway.
Same thing with QML. QML files get compiled into the application. The QQmlEngine then interprets various expressions/actions at runtime. Just like scripting a QWidget/QDeclarativeView based application with QtScript.
I think the post you have linked to was simply comparing QML as a language to a HTML and how Javascript can be used as glue code to script various actions, and how you can expose business logic to javascript via. FFI.
<button onClick="console.log('hello')" />
Button { onClick: console.log('hello') }
Button *button = new Button(parent);
connect(button, &Button::clicked, [](){ qDebug() << "hello" });
I know where you're coming from. What I am saying was it is less about preferences and more about separation of concerns. "What the UI should look like" vs. "What the UI should do". The latter usually needs to happen in C++ anyways. But the former - there are better tools/ways to describe that.
Most of the time "What the UI should look like" probably gets described in your constructors. It probably takes a few write/compile/test iterations to get what you want. That works well enough for simpler uis. When things get more complex... that's when other tools can simplify your work. With UIC, you (or an actual designer) can visually edit the ui in QtDesigner and give you the ui files. All the UI description gets compiled to it's own class. Your business logic code wouldn't have to worry about details of layouts, positions, colors etc... It wouldn't have to be modified whenever you want to change the position of a button.
fwiw I started appreciating the designer only after going back to writing QWidgets code after a few years of break
The extra feature of the QML engine wrt. a web browser is to provide callbacks and hooks, doing what I guess we could call FFI, allowing for events and function calls to travel between C++ and JS. Complex, but not much sort of magic in there.
As far as I understand, we would draw a parallel between QML and what Tauri does. It just embeds a whole interpreter into your program, in order to be able to draw the markup and run the scripting.
The build system automatically embeds all the QML files into the program binary. The QObject system transparently adds reflection to C++, using the build system. The QmlEngine that keeps track of properties that are in use and automatically updating the dependent values, and the headaches that come with broken bindings.
Not saying it is a big deal to learn or anything, but a lot of this stuff is not what "traditional C++ devs" are used to. I had to teach some new devs "Intro to Qt for C++ progammers", so i got to see this from their perspective.
C++ programmers would probably be used to lower level kind of technologies, but when talking about this I think it just helps to think about what would you do if you wanted to embed an HTML and JS file into your program and wanted it to work like QML works.
For an experienced C++ dev, a list of stuff will naturally start flowing through their mind:
* A mechanism to inject the files into the binary upon compilation.
* How to interpret the HTML and paint on the screen? We'll need an HTML rendering engine and a surface painter.
* About JS, how to run it? Well, maybe time to include V8 into the program. It will take care of running JS code.
* Now to make calls between both languages. Probably V8 already provides callbacks because it implements FFI already for you.
* And other stuff you mentioned, like a property manager that remembers what has been registered and creates change observers in order to trigger events for C++ to know.
Thing is, Qt already gives you all of this done, otherwise their proposal of QML wouldn't have gone too far...
These series of articles touch on the topic and can enlighten a bit about some details:
* https://www.kdab.com/qml-engine-internals-part-1-qml-file-lo...
* https://www.kdab.com/qml-engine-internals-part-2-bindings/
* https://www.kdab.com/qml-engine-internals-part-3-binding-typ...
* https://www.kdab.com/qml-engine-internals-part-4-custom-pars...
It is just that for them, "non c++" tools ended up doing a lot of this magic work. Plus the idea of "embedding another language or two into a language where i already made UI without any fuss" tended to keep some of the more experienced C++ devs away from QML in my experience. Giving them tasks like animating the UI, writing custom styles etc.. that's where QML converted more C++ devs in my experience.
Those kdab blogposts were indeed very helpful for us back then.
That’s usually what people mean by magic, extra complexity that is not apparently beneficial even when partially understood.