[Development] QML import versions

[Attila Csipa]

On 9/21/2015 10:51 PM, Alan Alpert wrote:
> I found part of the previous discussion, see my essay from 2012 which
> explains the versioning system:http://alan.imagin-itis.net/?p=322

Not a new discussion, indeed :)
> Now in the next minor version of Qt, say we add a QQmlFlange class to
> QtQml. A application built against the current version of Qt, but
> linking to system libraries, will continue to work fine. The name
> resolution happened at the linker stage and so a new symbol in the
> shared library doesn't affect the behavior of the compiled binary.
> "flange" will still be an instance of the local QQmlFlange and you
> won't hit the name conflict until you try to compile against the new
> Qt version.
>
> Contrast to the example I gave Robin, where the QML name resolution
> happens at runtime, and you can see why #include<QtQml> is so much
> safer than import QtQml.

This is a red herring - given MOC and QObject properties, there is no 
guarantee (other a statistical "we add less properites to C++ classes 
than to QML, so there is less change of namespace overlap"). At best, 
this would indicate differences of defaults, but not versioning enforcement.

Here's an example:

     QScreen* scr = qApp->screens().at(0);

     qDebug() << scr->property("devicePixelRatio");
     qDebug() << scr->setProperty("devicePixelRatio", 100);
     qDebug() << scr->property("devicePixelRatio");

On Qt5.3, this gives

//    QVariant(Invalid)
//    false
//    QVariant(int, 100)

On Qt5.5, this gives

//    QVariant(double, 1)
//    false
//    QVariant(double, 1)

It's clear that there will be no compile time difference, but given the 
different *runtime* outcomes, the app behavior can be altered completely 
transparently to the developer. That's why it feels that the QML 
versioning *enforcement* is pretty arbitrary, as both C++ and QML can be 
written in both static and dynamic manners. Even if we say that "well Qt 
on the C++ side doesn't use properties that often", it doesn't take into 
account 3rd party code, or how much it (doesn't) rely on either QML or 
C++ properties in it's own classes.

The rigidity of the versioning (good luck using different QML features 
for say Qt5.4 vs Qt5.5), and the "feature available from Qt5.3, now 
guess what import that is" in the documentation is an insult to this 
injury. QML today just doesn't have a mechanism for maintaining 
compatibility with multiple versions of Qt - you need to peg it to a 
specific version, or suffer, and the aforementioned versioning rigidity 
plays a major role in this.

>> Finally, no matter how you pin, you will be getting the new
>> implementation - is there an example that Qt actually retained a
>> different implementation for older imports, not counting QtQuick1 vs
>> QtQuick2?
> Yes, QtQuick.Window 2.0 is implemented using the QQuickWindow class,
> in QtQuick.Window 2.1 we moved it to QQuickWindowImpl. Not an entirely
> separate implementation, and the differences are deliberately minor
> (because it's a minor version) but if we added a QtQuick.Window 3.0
> any time soon we'd keep these two classes around.

OK, at least some use for that - the nasty part here is that the 
documentation is less than helpful with the versioning. Though in that 
case it must be noted this cuts two ways - the implication is that you 
might be left out of fixes and/or performance improvements that might 
have happened in that following minor release.

> Okay, so you bump to the latest version instead of the strict minimum 
> required whenever you touch a property that doesn't exist. You still 
> don't need to update files that aren't using any "new" features.

You're also touching the version when you create a new file as the docs 
and tooling are geared towards "latest is greatest". Aiming for 
compatibility with a certain version of Qt is really difficult unless 
you know the exact import version - Qt version relation (or willing to 
develop with the older Qt). Plus, javascript is really not meant for 
this versioned type of work. While syntax highlighting help with static 
QML element properties, there is no help for checking if you don't refer 
to a non-existent property in your javascript somewhere (especially if 
it's hidden away in an import). Long story short, I understand why you 
would like QML versioned, but the way things are implemented today, that 
benefit is rather limited, and not without drawbacks.

Regards,
Attila