On Sun, Sep 20, 2015 at 4:55 AM, Filippo Cucchetto <[email protected]> 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
