[Development] QML engine C++ class renaming

[Alan Alpert]

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
> 
> wrote:
> > 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
> "QQml".

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

-- 
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks