The (former) lack of QTreeView and problems in styling QtQuick Controls
are not actually about the QML language. They are about QtQuick and
QtQuick Controls. I feel that I have to again remind you all that those
are different things.
If you are willing to use private API, you can build your application in
C++ using QtQuick today. You don't need to use QML for that. People have
done it [1].
Conversely, you don't have to use QtQuick in your QML code. You can
write your own QML modules that do something completely unrelated.
Someone has written a QML module that exposes QtWidgets to QML [2]. It
is somewhat dated by now. Don't use it. However, we can clearly see that
this is possible.
I do agree that we still need to improve on the ways you can pass data
between QML and C++ (or other languages). However, using C++ all the way
is not an ideal solution either. Let me list some benefits of QML over
C++ for building UIs:
1. Safety: If you let your typical frontend developer who usually writes
HTML and CSS write C++ instead you are going to give yourself a lot of
headaches with crashes, memory leaks, and generally unexpected behavior.
C++ is just too dangerous for most people. QML shields you from these
problems, by making the boundary between frontend and backend explicit,
and doesn't let you play with the C++ data structures directly. While
that gives me a lot of headaches about how to transfer between the
languages, it cures other peoples' headaches. Safety has been a big
topic all over the industry lately, and we should listen to that.
2. Bindings: Bindings are actually the superpower that allows you to
express relations between values in a very concise way. It turns out
that this makes writing UIs a lot easier, and the resulting code a lot
clearer. Bindings are seamlessly integrated in QML. All your expressions
are automatically bindings. You don't have to think about whether the
Q_PROPERTY you are using has a BINDABLE or a NOTIFY and you don't have
to think about connecting the signal and initializing in the right order
in the latter case. It just works. Sure, we have QProperty and QBindable
now in C++, but we haven't been able to make them universally usable.
There are still a lot of Q_PROPERTYs that are not BINDABLE. And even if
they all were, you could still easily mess it up by forgetting to
declare your own properties as QProperty.
3. Clarity: Having dedicated syntax to construct hierarchies of objects
is immensely helpful for building user interfaces. Most user interfaces
consist of some hierarchical construction of graphical elements, and
being able to see that in the code is vital. I have seen some pure C++
constructions that look kind of similar to QML. If those were public I
could discuss them here. We might take them into account when improving
qmltc [3]. If we have an elegant way to express object hierarchies in
C++, qmltc might generate that. You might then opt to instead write the
same thing manually. I wouldn't be opposed to that.
4. Rapid prototyping: With QML you can omit the compile step and
directly see the results of your changes by using e.g. qmlpreview. The
quick turnaround really helps when developing user interfaces. It might
be possible to achieve the same thing using a C++ interpreter, but I
would expect it to be more difficult. Many facts about your C++ program
are actually communicated outside the actual code, via the build system,
the include path, etc. With QML we control the whole stack. We can hook
into the running binary and directly change the relevant data structures
at run time. Sure, this particular feature in QML is still not as good
as it should be, but changing to C++ would probably make it harder to
improve.
[1] https://qskinny.github.io/
[2] https://github.com/KDABLabs/DeclarativeWidgets
[3] https://doc.qt.io/qt-6/qtqml-qml-type-compiler.html
best regards,
Ulf
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
