[Qt-qml] Separation of QtQuick 1 from QtDeclarative repo

[matthe...@nokia.com]

As sent to the qt-development list:

As the first part of the changes described by QTBUG-23737, we have now separated version 1 of Qt Quick from the qt5 qtdeclarative module.

The implementation of Qt Quick 1 is now hosted in the 'qtquick1' repository ( http://qt.gitorious.org/qt/qtquick1 ). For maximum compatibility with the existing version of Qt Quick, this repository was created by importing the current implementation of Qt Quick from 4.8, using the JavaScriptCore engine, modified to build in the Qt5 environment. This repo is not yet integrated into the qt5 meta repo.

The qtquick1 repo produces a single library (QtQuick1) containing both the declarative engine and the Qt Quick 1 QML elements. The 'qmlviewer' utility is now hosted in the qtquick1 repo, and only loads QML files importing version 1 of QtQuick. The 'qmlscene' utility remains in the qtdeclarative repo, and only loads QML files importing version 2 of QtQuick.

Code linking against the qtquick1 implementation of Qt Quick should specify 'QT += quick1'. Code linking against the current version of the declarative engine should specify 'QT += declarative', and 'Qt += quick' to link against the QtQuick 2 QML elements.

Matt
_______________________________________________
Qt-qml mailing list
Qt-...@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt-qml

[Adriano Rezende]

On Fri, Feb 3, 2012 at 1:39 AM, <matthe...@nokia.com> wrote:

As sent to the qt-development list:

As the first part of the changes described by QTBUG-23737, we have now separated version 1 of Qt Quick from the qt5 qtdeclarative module.

The implementation of Qt Quick 1 is now hosted in the 'qtquick1' repository ( http://qt.gitorious.org/qt/qtquick1 ).  For maximum compatibility with the existing version of Qt Quick, this repository was created by importing the current implementation of Qt Quick from 4.8, using the JavaScriptCore engine, modified to build in the Qt5 environment.  This repo is not yet integrated into the qt5 meta repo.

The qtquick1 repo produces a single library (QtQuick1) containing both the declarative engine and the Qt Quick 1 QML elements.  The 'qmlviewer' utility is now hosted in the qtquick1 repo, and only loads QML files importing version 1 of QtQuick.  The 'qmlscene' utility remains in the qtdeclarative repo, and only loads QML files importing version 2 of QtQuick.

Code linking against the qtquick1 implementation of Qt Quick should specify 'QT += quick1'.  Code linking against the current version of the declarative engine should specify 'QT += declarative', and 'Qt += quick' to link against the QtQuick 2 QML elements.

 
Why is it needed to import 'declarative' and 'quick' for QtQuick2? I think it would be better to have 'QT += declarative' for QtQuick1 and 'QT += quick' for QtQuick2.

Is there a plan to share a common module for QtQuick1 and QtQuick2 or it will have duplicated code for the common parts? If no sharing is planned it would also be better to change the class names in the declarative module, so it would not result in name clashes when importing qtquick1 and qtquick2.

Br,
Adriano

[matthe...@nokia.com]

Hi Adriano.

 

Currently, ‘QT += declarative’ adds the headers and library for the declarative UI engine, while ‘QT += quick’ adds the headers and library for the Qt Quick 2 QML components.  An application may choose to use the declarative engine without the bundled components.  In the first version of Qt Quick, both aspects were bundled together into a single library, which is now present in Qt 5 as the ‘quick1’ module.

 

The plan is to have these both available in Qt  5 as independent modules.  For this, we need to have different module names, and symbol names that do not clash.  I will rename all the classes currently named ‘QDeclarative…’ in the qtdeclarative module to ‘Qml…’ or ‘QQuick…’ as appropriate.  This is slightly held up by the fact that we would like a small change to moc to preserve backward compatibility.

 

Matt

[Adriano Rezende]

On Sun, Feb 5, 2012 at 8:29 PM, <matthe...@nokia.com> wrote:

Currently, ‘QT += declarative’ adds the headers and library for the declarative UI engine, while ‘QT += quick’ adds the headers and library for the Qt Quick 2 QML components.  An application may choose to use the declarative engine without the bundled components.  In the first version of Qt Quick, both aspects were bundled together into a single library, which is now present in Qt 5 as the ‘quick1’ module.

 

The plan is to have these both available in Qt  5 as independent modules.  For this, we need to have different module names, and symbol names that do not clash.  I will rename all the classes currently named ‘QDeclarative…’ in the qtdeclarative module to ‘Qml…’ or ‘QQuick…’ as appropriate.  This is slightly held up by the fact that we would like a small change to moc to preserve backward compatibility.

I see. That separation would be nice; I thought QtQuick2 would also bundle engine and components in the same module. However, I think the 'declarative' module name is misleading when used for QtQuick2 because all class prefixes in this new module won't be 'QDeclarative*' anymore and also because it doesn't highlight that this module just contains the engine. Maybe something like 'QT += quickcore quickcomponents' would be more clear.
For QtQuick1, on the other hand, 'declarative' has some meaning due historical reasons and the API itself, but 'quick1'  would also be a good module name.

Regarding the 'Qml*' prefix option; I would vote against it, since it doesn't follow the Qt name standards. AFAIK, the 'Q' prefix should be present in all classes followed by the class name in camel-case. As QML is an acronym for itself, it should have a Q prefix as well, like 'QXml*', 'QDom*' and others. But I would vote for the 'QQuick*' prefix instead, since it's already being used in the rest of the API.

Br,
Adriano