[Interest] QGraphicsView and OpenGL in Qt6

[Ulf Hermann]

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