On Thu, 16 Feb 2012 12:07:54 ext d3fault wrote: > I understand that QML/Quick is young, which justifies breaking backwards > compatibility as it matures... but thinking longer-term, wouldn't it be > better to call the newest QtQuick (2.0) just QtQuick and the 1.0 version > Qt4Quick... to retain backwards compatibility? Does this promise of > backwards compatibility only last for one major version number change? > Isn't Qt 3 support being dropped with the release of Qt 5? Wouldn't that > imply that support for Qt Quick 1.0 is going to be dropped for the Qt 6 > release? I see no point in making a promise, going through all the extra > effort of maintaining it... and then just dropping it later. We might as > well drop support for Qt Quick 1.0 now and force the (albeit painful) > upgrade process NOW rather than later (when they have EVEN MORE code > written dependent on Quick 1.0).
The way QML compatibility is supposed to work is different from C++. Even for a minor version, you don't always just jump to the latest version. Your application continues using the version it was developed for until you choose to update it, deliberately, to a more recent version (note that if the C++ library updates you may get bugfixes transparently, this is primarily about feature additions/changes). Considering the amount of effort it could take to port your QtQuick 1.0 application to QtQuick 2.0, I'd think QML users would be really happy to have this sort of grace period where both will work; even if it's of indeterminate length. This does mean that QtQuick 1.0, at least the QML elements, should be available for people for some time. The theoretical stance is that it should stick around eternally (in QML, if not in C++) but I doubt that will happen due to the immense changes in the QtQuick module from 1.0 to 2.0. The deprecation path however has not been decided, so for now it's just sticking around. > As an aside, what's the difference between qml and quick? I thought they > were the same thing. Why is QT += qml quick necessary? Seems like it should > be one or the other. Sorry if this is noob'ish. The QML language is not strictly bound to the QtQuick element set. For example, the cool new QBS prototype appears to use the QML language with a different set of elements appropriate for a build system (instead of GUI elements). > Developers wishing to compile their Quick 1.0 code on Qt 5 should be forced > to do QT += qt4quick or something, explicitly asking for backwards > compatibility (assuming my paragraph above is ignored... which I'm guessing > it will be...). New code should just be QT += quick... and hopefully Quick > matures enough so that backwards compatibility isn't broken again. That's already done. You do QT += quick1 to get the old ones, and QT += quick to get the new ones. However, this is in addition to the name changes. So you'll need more changes than just to the .pro file. -- Alan Alpert Senior Engineer Nokia, Qt Development Frameworks _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
