[Development] QML engine C++ class renaming
alan.alpert at nokia.com
Thu Feb 16 03:26:50 CET 2012
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
> 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
> 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.
Nokia, Qt Development Frameworks
More information about the Development