[Development] QML import versions

Alan Alpert 416365416c at gmail.com
Sun Sep 20 23:59:57 CEST 2015


On Sun, Sep 20, 2015 at 4:55 AM, Filippo Cucchetto
<filippocucchetto at gmail.com> wrote:
> 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

Yes, this sort of thing could work (probably use the keyword "from"
instead of "as in", or some other reserved word).

I think last time this was put forward we considered implementing it
with "metamodules" that are just lists so that we could have a
qml/Qt5/qmldir that looks like

<...>
QtQuick 2.4 since 5.4
QtQuick 2.5 since 5.5
QtQuick.Particles 2.0 since 5.0
<..>

And that would be a file that the mapping comes from and is parsed by
the engine when it sees a "QtQuick from Qt 5.5". It would also be
generic enough so that module bundles other than Qt essentials could
use it.

The pitfall last time was that it's language work no-one has time for :( .

> 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
>

If you don't break from the name resolution case, you'll break when
the major version updates and things are expected to break. Could work
if you statically link Qt into your application, but if you're using
system libraries you're doomed.

--
Alan Alpert



More information about the Development mailing list