[Development] QML import versions

Sun Sep 20 15:35:15 CEST 2015

Hi,

I always had that feeling too, that QML import versions are confusing if you don’t have any IDE to give you direct insight on what is available. If I put my user hat, I can see three reasons on why I’m usually fiddling with the import version:

1) Which major version of the plugin do I want? (e.g. QtQuick 2 vs 1, QtWebKit 3 vs 1, QtQuick.Controls 2 vs 1)
2) Which minimal version of Qt do I want my app to be able to run on? The minor version of each imported module should be: At most the version that was shipped with that Qt.
3) Which version do I need for all the properties that I want to use? The minor version of each imported module should be: At least the version that each of the necessary property was introduced.

A few things to think about those user objectives:

- It would be nice to be able to increase a module’s major version without waiting for Qt6, else we would have to replace “import QtQuick.Controls 2.0” by “import QtQuick.Controls2 1.0” or “import QtQuick.ControlsNg 1.0”
- I don’t see an advantage for neither the user, or for us, to allow “import QtQuick 2.0” when the app’s minimum supported Qt version is 5.5. It would be as good for everybody if QtQuick 2.6 (or whichever version came with Qt 5.5) was implied. So it seems to make sense to just specify “I want to support Qt >= 5.5 and just fail if I’m using a property revision not available in that version for any imported module” and the user wouldn’t need to worry about 3) at all.

I’m neither strongly against the status quo or using the Qt version for the imports, but one alternative solution (not perfect, just to give ideas) could be to have a way specifying the minimum Qt version app-wide like it’s possible on iOS / OS X. Something like:

QQuickView view;

view.setSource(…); <— “import Qt 5.5; import QtQuick.Controls 2; import QtWebEngine 1; …"
// Or
view.setMinimumQtVersion(5, 5); // Could default to the Qt version used to deploy the app
view.setSource(…); <— “import QtQuick.Controls 2; import QtWebEngine 1; …"
// Or just always decide at compile time and import the maximum for each module:
view.setSource(…); <— “import QtQuick.Controls 2; import QtWebEngine 1; …”

Cheers,
Jocelyn

> On 20 Sep 2015, at 13:43, Nurmi J-P <jpnurmi at theqtcompany.com> wrote:
> 
> Hi Alan,
> 
>> On 18 Sep 2015, at 20:13, Alan Alpert <416365416c at gmail.com> wrote:
>> 
>> On Fri, Sep 18, 2015 at 8:12 AM, Nurmi J-P <jpnurmi at theqtcompany.com> wrote:
>>> Hi all,
>>> 
>>> I'd like to propose that all QML imports that are part of the Qt Essentials start following the respective Qt version number.
>>> 
>>> Let's take a look at the version history of some of the QtQml and QtQuick imports.
>> 
>> You missed a few key ones at the beginning:
>> 
>> ### Qt 4.7.0
>> 
>> - Qt 4.7
>> 
>> ### Qt 4.7.1
>> 
>> - QtQuick 1.0
>> 
>> ### Qt 4.7.4
>> 
>> - QtQuick 1.1
> 
> 
> Heh, yeah, I was focusing on how the situation looks like to a user that installs Qt these days, but we can bring in the whole history to the discussion. To me, this doesn’t make the QML versioning look anyhow better, but more like a way to bend the rules. Greetings to the Nokia machinery that desperately needed new features but couldn’t afford waiting for the next minor version of Qt.
> 
> 
>>> ### Qt 5.0
>>> 
>>> - QtQml 2.0
>>> - QtQuick 2.0
>>> - QtQuick.Particles 2.0
>>> 
>>> In the beginning, everything was cute, fluffy, and consistent.
>> 
>> QtQuick 1.1 was still around, just wholly incompatible with the
>> previous modules (something we'd like to avoid in the future). That's
>> why QtQuick.Particles started at 2.x, because series 1 was still
>> active (and there is a QtQuick.Particles 1.0 implementation somewhere
>> too).
>> 
>> Note also that around the Qt 5.0 release, and ever since, there were a
>> lot of discussions about getting back to the Qt version number. Sadly
>> I can't seem to find the emails right now. I seem to recall that the
>> Qt Mobility modules went that direction in Qt 4.7 times (I'll need
>> someone else to tell the story of how that went).
> 
> 
> What happens in the past, stays in the past. :) Incompatibility between Qt Quick 1 and 2 is not that different from incompatibility between Qt 4 and 5. It’s too late to speculate on that, but perhaps it was a mistake to pull Qt Quick 1 into Qt 5...
> 
> 
>>> Everyone can judge by themselves how coherent this looks like. :) A while ago the Qt Creator team needed help (QTCREATORBUG-14575) figuring out the available import versions in different Qt releases. I had lost track a long ago, so I actually had to read git log to find out. Now imagine a poor new user that installs Qt. It might not always be the latest available version, but specified by the project. How are they supposed to navigate in this jungle of QML versions?
>> 
>> They use the version with the features they need, instead of trying to
>> use a "latest" which they may not need? For users and Qt Creator
>> purposes we've discussed keeping a mapping or a wiki page, but that
>> never seemed to get off the ground. If we could keep the .qmltypes
>> files up to date, then that could be a viable mechanism too.
> 
> 
> Think about the documentation, for instance.
> 
> If a property documentation says “introduced in Qt 5.9", the user doesn’t know what version to import in QML. If it says “introduced in QtQuick.Layouts 1.5”, the user doesn’t know what Qt version is required.
> 
> A wiki page with a huge version mapping table doesn’t seem like an attractive solution. 
> 
> 
>>> What makes the situation even more cumbersome, to ourselves who develop these modules, is that there's no convention on how new properties are revisioned. Some classes are using a running revision number that gets incremented whenever new members are added, whereas others match it with the minor version of the module or Qt.
>> 
>> The former is the "official" convention (not that I know where it's
>> documented ;) ). As it's an internal development detail I'm not
>> surprised it's slipped through code review.
> 
> 
> Here's a pseudo code review request that adds a new property:
> 
>    + Q_PROPERTY(int foo READ foo WRITE foo NOTIFY fooChanged REVISION 3)
> 
>    + qmlRegisterType<QQuickSomething,3>(uri, 1, 7, “Something”);
> 
> How do I know that any of the above numbers are correct? If they matched the Qt version, I could tell without looking up in the code or git history.
> 
> 
>>> Is this something that would be possible to implement already in Qt 5, or is this Qt 6 material? Does someone strongly oppose the idea? How often do we release new major versions of QML modules? I don't see why QML modules couldn't follow the same practices than the rest of Qt follows. Ironically, we've been working on this thing called Qt Quick Controls 2.0... :P
>> 
>> So what's not possible is the conceptual conflict between arbitrary
>> and semantic version numbers.
> 
> Qt, as a whole, uses semantic versioning. I wish that was that only version number that users had to remember.
> 
> --
> J-P Nurmi
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org <mailto:Development at qt-project.org>
> http://lists.qt-project.org/mailman/listinfo/development <http://lists.qt-project.org/mailman/listinfo/development>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150920/fd684500/attachment.html>