[Development] QML engine C++ class renaming

[Alan Alpert]

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