[Development] QML engine C++ class renaming
alan.alpert at nokia.com
Wed Feb 15 09:59:45 CET 2012
On Wed, 15 Feb 2012 18:46:34 ext Thiago Macieira wrote:
> On quarta-feira, 15 de fevereiro de 2012 08.22.17, martin.jones at nokia.com
> > This is a heads-up regarding the renaming of QML C++ classes. As per
> > https://bugreports.qt-project.org/browse/QTBUG-23737 class names that
> > currently begin with QDeclarative* will be renamed Qml*, for example
> > QDeclarativeEngine will become QmlEngine.
> Q followed by lowercase letters used to be reserved for third-party
> implementations. The Q in Qt classes means Qt itself, it's not the first
> letter in another acronym. So these classes should actually be called
The Q in QML means Qt itself. I'd be happy with QMlEngine if that floats your
boat (except we probably aren't renaming everything again just to change
capitalization :P ).
> I'm more worried that we're now duplicating the entire set of QML language-
> support classes in the Qt Quick 1 and 2 modules. That means there's
> absolutely no chance of compatibility in C++ between 1 and 2...
> But was there any? I mean, if the use of the scene graph already made every
> single C++ usage of QML have to be modified, there's no further harm by
> renaming some classes.
Correct, the change to scenegraph means that any C++ graphical items written
for QtQuick 1 would have to change anyways.
The two theoretical cases which might have been compatible are non-graphical
QML libraries (which I don't think exist yet) and really dumb QML launchers
(which still probably should make a conscious switch to scenegraph as it
involves a fundamental change in rendering that you ought to be prepared for).
> One final question: is it possible for the Qt Quick 1 module to use the
> Quick 2 language module (QT += qml) and simply wrap it with its
> QDeclarative classes, retaining compatibility?
There have been some incompatible changes, such as moving the local storage
API out of the engine. While they haven't been that many, it would certainly
not be a simple wrapping and you'd also lose a lot of 'bug compatibility' (in
the 'behaviour change sense', not the 'stopped crashing' sense).
Nokia, Qt Development Frameworks
More information about the Development