[Development] QML import versions
Filippo Cucchetto
filippocucchetto at gmail.com
Mon Sep 21 13:08:57 CEST 2015
I agree with most of what has been said by everyone here.
What i see it's there're two problems:
1) A way to specify a QML module version based on a Qt release
2) A way to decentralize the version used in several .qml files or of an
entire project
To me we should focus on (1) since (2) could be solved later and we can get
support
from an IDE refactoring tool (i'm thinking of a QtCreator refactor action).
Furthermore the (2) should not disable the ability of a dev to import a
specific version
in a single file (so overriding a global setting).
For (1) i like what has been proposed by Alan so
import QtQuick from Qt 5.5
feels nice to me
For (2) i agree with Simon in creating a custom file with some format for
specifing
the import version. Thus allowing a dev to just write
import QtQuick
At the end someone could also argue that we could provide custom files (2)
for each Qt
release and so (1) could be skipped.
The user just need to copy one of this files to its own project dir and be
done.
Supposing to name the file "MyCustomConf.qmlversion" the content could be
something like
this (and maybe with a qml syntax)
import QtVersion 1.0
Modules {
Module { name: "QtQuick"; version: "2.5" }
Module { name: "QtQuick.Controls"; version: "1.4" }
...
Module { name: "QtQuick.Layouts"; version: QtVersion.since(Qt.55) }
}
2015-09-21 12:36 GMT+02:00 Hausmann Simon <Simon.Hausmann at theqtcompany.com>:
> Hi,
>
>
> I agree that something "new" needs to be put on the table in order to
> solve this. And "this" expands unfortunately
>
> to a few issues at the same time.
>
>
> I think that it would be a mistake of "import QtQuick" - without any
> version tag - would always import the latest available
>
> version on the system. If we look into other development communities with
> package based environments such as Python (pip)
>
> or Go, then we can see that the approach of automatically always importing
> the latest version is known to cause more headaches
>
> than do good. Very quickly the users want to be able to _pin_ to a certain
> version and be themselves in control when to "upgrade"
>
> to newer API.
>
>
> I think that we should learn from this and this is why I think generally
> applying a version to the QML APIs is a good thing. I believe that what
>
> we are missing is the convenience of making the conscious step of changing
> the of QtQuick 2.4 to 2.5 - it is incredibly tedious at this
>
> point as it requires touching every single file.
>
>
> Therefore I think that we should introduce the notion of configuration
> files that apply to an entire project. For QML modules that configuration
>
> file is the qmldir file, although I'd prefer something different. For
> applications - the primary target audience in this thread - we are lacking a
>
> central place where we could say that
>
>
> import QtQuick
>
>
>
> should resolve to exactly version 2.4.
>
>
> In other words: I think we should allow application developers to use just
> "import QtQuick" in their qml files - without a version. But all that
>
> should mean is that when the engine encounters a version-less import, it
> should look for the project configuration file to pick the version the
>
> developer would like to choose.
>
>
> This way one developer can try to bump the version in their copy of the
> application source code, try the app and see if there are any property
>
> conflicts that needs resolving. Then he can commit that version bump,
> possibly together with files to .qml files that resolve conflicts.
>
>
>
>
> Simon
>
>
> ------------------------------
> *From:* development-bounces+simon.hausmann=theqtcompany.com at qt-project.org
> <development-bounces+simon.hausmann=theqtcompany.com at qt-project.org> on
> behalf of Filippo Cucchetto <filippocucchetto at gmail.com>
> *Sent:* Sunday, September 20, 2015 13:55
> *To:* Nurmi J-P
> *Cc:* development at qt-project.org
> *Subject:* Re: [Development] QML import versions
>
> I'm no troll, but i don't see any way to solve this without putting
> something new to the table
>
> 1) What about extending the a little bit the QML language itself.
> Something like
> import QtQuick as in 5.5
> import QtQuick.Controls as in 5.5
>
> so a way to specify to import a module at version when a specific Qt
> version was released.
> Obviusly this doesn't disable the option for specifying a particular
> version.
> So this should be fine
> import QtQuick as in 5.5
> import QtQuick.Controls 1.4
>
> 2) Another option is automatically use the latest version of a module if
> the version number
> is not specified. So:
> import QtQuick // Automatically imported with the latest version installed
> import QtQuick.Controls // Automatically imported with the latest version
> installed
>
>
>
> 2015-09-20 13:43 GMT+02:00 Nurmi J-P <jpnurmi at theqtcompany.com>:
>
>> 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
>> http://lists.qt-project.org/mailman/listinfo/development
>>
>
>
>
> --
> Filippo Cucchetto
>
--
Filippo Cucchetto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150921/eedcb8c2/attachment.html>
More information about the Development
mailing list