[Development] QTCS2019 Notes from QtQml session

[Shawn Rutledge]

> On 25 Nov 2019, at 22:18, Filippo Cucchetto <filippocucchetto at gmail.com> wrote:
> 
> Having followed the evolution and first announcement of Qml/Quick QML3 seems like an admission of guilt.
> I remember when a lot of people complained about the use of Javascript as a scripting language and further
> more on the lack of a public C++ API. Now it seems like some of the QML problems are going to be fixed
> but still i wonder if instead of putting man power in cutting QML2 we could bring first citizen C++ QtQuick API.
> Playing the devil's advocate why can't we leave QML2 as is and instead use the new pseudo declarative
> C++ syntax and code everything in C++? I mean...we want speed? you want speed? use plain C++.

There’s nothing wrong with a little syntactic sugar, as long as we stay committed to the translation that we choose.  A code generator that starts with QML source is not worse than moc or uic or qrc.  (I still think we could have done better performance-wise by writing a real compiler rather than writing C++ source code that then needs to be parsed again, but at least you will presumably have a chance to read the C++ code that it generates, which should help with understanding what it does.)

Another thing that came up at QtCS though (during the break, not during the session) is that as soon as we make it possible for customers to ship binaries that run QML that has been compiled in C++ form, rather than interpreted QML, if those same customers also expect the usual binary compatibility guarantee (to be able to upgrade Qt and still keep running the same compiled binary), then it’s a precondition to apply the same binary-compatibility rules to everything that Qt Quick exposes to QML.  Those headers will have to follow the same rules that every other public API does.  That worries me a bit, because it will remove a degree of freedom that we have enjoyed in Qt 5, which made it easier to fix API mistakes, extend existing APIs to support different data types, etc.

If we will lose flexibility to change any QML-exposed APIs in any binary-incompatible way after Qt 6, then we might as well make all the headers public too, right?  The only reason they weren’t (that I’m aware of), was to retain flexibility to change C++ API, as long as QML API continued to work the same.  This will satisfy people like you who keep asking for C++ API over and over, but also will make it much harder to fix any API mistakes that remain.

So it seems that there’s a really big chunk of work I didn’t know about, to get ready for Qt 6: use the PIMPL pattern everywhere (we mostly did that already though), rename the headers, make sure the data storage is always in the private class, do API review of _everything_ to make sure we aren’t exposing any unmaintainable public C++ API, make sure our use of data types is consistent, etc.  And that’s for every module that exposes anything to QML, not just in qtdeclarative.  Other things that we could be doing will probably need to be postponed because of that.

For example we still aren’t sure whether QVariant, QVariantList and such are good data types to use in QML-exposed APIs, and therefore haven’t been consistent about it.  We might end up wanting to change most of those.  Before, the QML engine could pave over some of the details for us (there are multiple ways to expose containers and composite objects, so it's been fine until now to use them all), but if we will have public API, we should be consistent.