[Development] QML engine C++ class renaming

d3fault d3faultdotxbe at gmail.com
Thu Feb 16 03:07:54 CET 2012

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

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.

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.

As for QQml vs Qml, Qml definitely reads better.. but QQml follows the
rules. Rules can be broken and/or changed, however. With Qml becoming such
a large part of the Qt experience (it seems to get way more attention than
the C++ part lately), I'd say it's worth the exception.


On Wed, Feb 15, 2012 at 4:41 AM, Artur Souza (MoRpHeUz) <
artur.souza at openbossa.org> wrote:

> On Wed, Feb 15, 2012 at 8:31 AM, Olivier Goffart <olivier at woboq.com>
> wrote:
> >
> > Anyway, this is a compatibility library. It's sole role is to be there
> to help
> > transition (just like qt3support was)
> I had the impression that most people agreed that qt3support was a
> mistake. Are we going to take the same strategy for Qt5? :)
> Cheers!
> --
> -------------------------------------------------------
> Artur Duque de Souza
> openBossa
> INdT - Instituto Nokia de Tecnologia
> -------------------------------------------------------
> Blog: http://blog.morpheuz.cc
> PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net
> -------------------------------------------------------
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120215/396aaf80/attachment.html>

More information about the Development mailing list