[Development] QTBUG-43096 - QML instantiation performance decadence

[Uwe Rathmann]

Hi Robin,

> From my own perspective, I think Controls 1 was a well-intentioned ...

Agreed and to be honest I'm really impressed about what was doable in QML, 
but it also showed where its limitations are.

But at the time, when Controls 2 has been started everything was on the 
table and - at least from the outside - it looked like a comfortable 
situation for making good decisions. And this is what I had expected to 
happen:

a) a solid C++ API with the same quality we are used
from all other Qt modules. Then the majority of the API is already 
available for QML by the standard mechanisms of the Qt/MetaObject system.

b) a thin layer on top to make the QML API feature complete.

Unfortunately I never noticed any indication pointing into the direction 
of a better C++ support. In fact the opposite happened: even the very 
base class of all QC 2 controls is not part of the public API ! 

> These are the key reasons I closed the bug -- I think
> that the message has been heard, improvements have been made, and
> hopefully things are now consistently heading in the right direction.

The stupid fact is that QML always comes at a cost. Trying to reduce 
these cost has been successfully done and any further improvements are 
welcome, but: as long as there is no clear separation between the Qt/
Quick graphic stack and QML I disagree, that the "right direction" has 
already been found.

> You mention qskinny. I think that experimentation is very cool, and it's
> great that it is working out for your project, and I am already familiar
> with it, but I'm not too interested in it personally, simply because the
> QML of "today" (having written a few libraries LOC of QML at this point)
> generally works well enough for me, and I find the convenience of the
> language very much worthwhile.

QSkinny is not about QML vs. C++ - it supports both, and some of the 
provided examples are in QML.

The reasons, why we are not using QML is because we decided so. And this 
is the opposite to our previous version, where we made the decision for 
QML because we had to.

--

Maybe a word on my intentions about QSkinny:

in the first place it is supposed to be the platform for the products of 
our company ( being in the automotive industry ). So writing the docs, 
polishing the skins ( = themes ) or completing the set of controls - 
steps that should be done to make the project more accessible - do not 
have the priority they deserve.

But I believe, that it is a good starting point to make more out of the 
Qt/Quick graphic stack as what we see today. And if in the end nobody 
else is interested ( in using or contributing ) it is good enough to 
demonstrate what is possible.

Uwe