[Development] Convenience Imports in QML

[Attila Csipa]

Short summary for the TL;DR crowd:

I don't necessarily care how different a shiny new API implementation is 
and if the fact that my application runs on it is purely coincidental 
based on how I use those APIs, but not having a way to say "YES, I know 
you bumped an API version, YES, I know there are potential 
incompatibilities, and YES, I tested it, and YES, it still works" is 
super-frustrating.


On 13-Dec-12 20:10, Alan Alpert wrote:
> On Wed, Dec 12, 2012 at 3:03 PM, Attila Csipa <qt at csipa.in.rs> wrote:
>
>> Yes, I agree on the principle, but the implementation gets in the way 
>> on many fronts. As said, there is no semantics or relation in the 
>> version numbers. Thus even if a new 2.1 *is* a known, verified, and 
>> perfectly compatible superset of 2.0, the import will get rejected 
>> (as far as the import mechanism is concerned, these versions could 
>> have been called "apple" and "orange"). 
> What do you mean, rejected? The existence of 2.1 doesn't invalidate
> the existence of 2.0. As they're within the same major version, 2.1
> and 2.0 elements can even live happily in the same tree.

The point is there is no implied compatibility or relationship 
guarantee. Doesn't invalidate but doesn't guarantee anything either, 
and, if done wrong (like the Maps API in Mobility 1.2), can be even 
detrimental.

> Wrong. If you bump the latest QtQml to 2.1 in Qt 5.2 we still provide 
> QtQml 2.0, so we break *NO* applications because *SOME* might be 
> incompatible. For the developers they need to update to use the latest 
> features but guess what? That's something they'd need to do anyways to 
> use the latest features.This is an even stronger compatibility than Qt 
> has, because if you try to run a Qt 4 application against Qt 5, it 
> breaks. If you try to run a QtQuick 1.0 application (which somehow 
> magically isn't a Qt 4 application as well) against Qt 5, it still 
> works. Same with QtQuick 1.1. Until you actually port your application 
> to use the awesome new features, it just works as before - which is 
> the best that a deployed application can do.

No, you're looking at it from the wrong angle. As a developer, I have no 
way of knowing up front what you will be bumping and what that implies 
for MY application.

QtQuick, an exception as it is, still demonstrates this well. Imagine my 
app using Rectangles only. I tested it with (Qt4.7, )QtQuick 1.0, 1.1 
and 2.0 import statements and *verified* it works with all. All is well. 
But if I use the common approach to use the lowest that works, that 
opens the following potential problems - what if the particular Qt5 
build I'm running on misses qtquick1 (to conserve space, incompatibility 
with cascades, you name it). Bork. What if Qt5 itself drops qtquick1 
from the list of supported modules? Bork on the next version. Even 
though there is a *known* and *verified* import statement. This is the 
difference in terms of academic discussions and the trench-engineering 
realities - I don't necessarily care how different a shiny new API 
implementation is and if the fact that my application runs on it is 
purely coincidental based on how I use those APIs, but not having a way 
to say "YES, I know you bumped an API version, YES, I know there are 
incompatibilities, and YES, I tested it, and YES, it still works" is 
super-frustrating.

The insult to injury is that the documentation is not too helpful wrt 
versioning. For example QtQuick 1.1 introduced a number of new 
properties for the Text element over QtQuick 1.0. Good luck finding out 
which properties you can use in a backwards compatible fashion from 
http://qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-text.html (which 
again pushes you to play it safe and always import the latest even if 
you don't necessarily need it).

>
> Wrong again. This is actually the same as Qt. If you wanted to use a
> new feature from 4.8.4 then you'd need a branch or an #ifdef because
> it wouldn't work against 4.5. If you didn't use any new features, it

It IS worse because there is *no* #ifdef in QML (unless you count the 
unreasonably cumbersome Component {} style loading), not even for the 
imports, much less the components themselves.

> just needed a recompile at most (and probably shouldn't have even
> needed that). Again, if you don't actually use any of the new features
> in QtQuick 1.1, you just leave your Qt 4.7.1 "import QtQuick 1.0" apps
> as "import QtQuick 1.0" and they'll still work fine with Qt 4.8.4.
> Shouldn't even need a recompile. If you want to use features from the
> new QtQuick 1.1 you'll have to update the import statements and use
> the new minor version as a minimum but again this is exactly the same
> as Qt.

As said, QtQuick is a good exception where this is *almost* true. It's 
an exception because it's the only module where the old version is still 
included, technically every other module has bumped versions in a lot 
less gentle way (Mobility stuff, Webkit, etc). And it's "almost true" 
because there was this "import Qt 4.7" glitch* in Qt 4.7.0. Again, I 
agree on the principle, but historically there was always a "good enough 
reason" (business, experience, maturity, deadline, you-name-it) why the 
clear QML versioning rules were implemented in a Matrix style 
some-rules-can-be-broken-some-can-be-bent way which made me a lot less 
enthusiastic about the general concept as implemented in Qt.

The bottom line is the QML versioning acts as a straightjacket (for a 
reason, no dispute there), the pain comes from not providing any 
mechanisms to compensate for the reduced mobility.

*an interesting "been there, done that" flashback that I got when the 
current "import Qt 5.0" proposal was made, we already had a "import Qt 
4.7" for the almost same purpose which was later renamed into QtQuick 
(which technically *was* the "essentials" of the 4.7 days).

Best regards,
Attila