[Development] Some Qt3D feedback

Knoll Lars Lars.Knoll at theqtcompany.com
Mon Jun 15 14:02:24 CEST 2015


On 12/06/15 16:59, "development-bounces+lars.knoll=theqtcompany.com at qt-project.org on behalf of Sean Harmer" <development-bounces+lars.knoll=theqtcompany.com at qt-project.org on behalf of sean.harmer at kdab.com> wrote:

>Thanks for structuring this! Much appreciated.
>
>On Friday 12 June 2015 22:23:09 Sze Howe Koh wrote:
>> First, a big thanks to Stephen for bringing the
>> I propose the following, with the hope that we formalise our decisions
>> at http://wiki.qt.io/Coding_Conventions for future reference.
>
>Agreed.
>
>> (1) Let's commit to extracting (and following) solid guidelines from
>> this experiment.
>> 
>> By the time we reach the Qt 5.6 feature freeze, we need to have clear
>> directions in the wiki on (i) what new modules in Qt 5.6+ should look
>> like, and ideally (ii) what all modules in Qt 6 should look like. Do
>> we convert QQmlComponent to QtQml::QComponent, or convert
>> Qt3D::QComponent to Q3DComponent?
>
>Agreed.
>
>> (2) Let's decide on how to name namespaces.
>> 
>> We recently got new namespaces with both the "Q" prefix
>> (QWebSocketProtocol) as well as the "Qt" prefix (QtWin, QtAndroid,
>> Qt3D). Which shall it be?
>
>I vote for the Qt prefix to match the header directory prefixes i.e.
>
>#include <QtCore/QThread>
>
>and
>
>namespace QtCore {
>class QThread
>}

That was IIRC the agreement we had during early Qt 5 development. Unfortunately we didn't pull through with it. I would also vote for all public namespaces to be prefixed with Qt in the future.

>
>just to pick an example for Qt6. Such a transition should be scriptable as a 
>porting tool to go from Qt5 -> Qt6
>
>> (3) Let's decide on how namespaces and #include headers should work
>> with each other.
>> 
>> There are a few sub-issues here:
>> 
>> a) We already have weird headers like <QtConcurrentRun>, and we almost
>> ended up with weird headers like <QWinFunctions> for the QtWin
>> namespace: https://codereview.qt-project.org/#/c/69108/ We need ground
>> rules on how to design header names around namespace names.
>> 
>> 
>> b) Should namespaces be #includable? Some are (QtWin, QTest), some
>> aren't (Qt3D).
>> 
>> 
>> c) At Qt 5.0's launch, the advice given to users was "Only #include
>> the class name, not the module name". In other words, use "#include
>> <QQmlComponent>", not "#include <QtQml/QQmlComponent>. However, if
>> class names are allowed to be non-unique, this advice must change. I
>> guess we revert to the old way of #including the module name along
>> with the class name?
>
>No strong opinion but with a slight preference for
>
>#include <QtQml/QQmlComponent>
>
>which in a namespaced world could become:
>
>#include <QtQml/QComponent>
>
>> (4) Let's decide on how to name QML types.
>> 
>> Spot the odd one out:
>> 
>> - (Qt Multimedia module) QCamera class -> Camera QML type
>> - (Qt 3D Core module) Qt3D::QCamera class -> Camera QML type
>> - (Qt QML module) QQmlComponent class -> Component QML type
>> - (Qt 3D Core module) Qt3D::QComponent class -> Component3D QML type
>
>We renamed the Component3D type from Component fairly recently at the request 
>of Konstantin Ritt to avoid a collision with QML's Component. I would prefer 
>to use namespacing here too. Again, this only becomes necessary when mixing 
>QtQML and Qt3D in the same QML file.

On the QML side, people can import with 'as', and we've never used any Q prefix there. So the whole namespace concepts fits a lot more naturally in there than in the existing C++ Qt world.

In addition, we'll anyway get more duplication of names with the new version of the Controls that are planned for 5.6. So we might as well start to live with it.

>
>> (5) Let's decide on the relationship between C++ modules and QML modules.
>> 
>> C++ classes are split between between "Qt 3D Core" and "Qt 3D
>> Renderer". QML types are not (everything is under "Qt3D". Do we want
>> this asymmetry?
>
>Not sure I understand this. We have qml imports for the Qt3D.Core, 
>Qt3D.Renderer and Qt3D.Input.
>
>There is an asymmetry that I don't particularly like in that the C++ classes 
>in the 3 Qt3D libraries are all under the generic Qt3D namespace. Thinking 
>about it I'd prefer to have those separated too i.e.
>
>namespace Qt3DCore {...}
>namespace Qt3DRenderer {...}
>namespace Qt3DInput {...}

Yes, in principle things should be symmetric between C++ and QML (if possible). In practice, these namespace names get pretty damn long. 
>
>> (6) Let's finalize: Is it "Qt 3D Render" or "Qt 3D Renderer"?
>> 
>> All other modules use:
>> * #include <QtModuleName> for the module-wide include
>> * QT += modulename for the .pro file
>> 
>> However, we currently have a "Qt 3D Render" module with:
>> * #include <Qt3DRenderer>
>> * QT += 3drenderer
>> 
>> Let's stick to existing conventions here.
>
>That was fixed yesterday to be Qt3DRenderer everywhere. Whether that's the best 
>name is still being discussed but at least it's consistent now.
>
>As an aside, my concern with the Qt3DRenderer name is that it's a verb whereas 
>other modules I can see being named along the lines of Qt3DPhysics, Qt3DAudio, 
>Qt3DSkeletalAnimation etc. In that scheme we should likely change the name 
>everywhere to Qt3DRender.
>
>> (7) (Unimportant in itself, but related to a few items above) Let's
>> decide on the definition of "module".
>> 
>> This word is seriously overloaded (and sometimes abused, e.g. "QtBase
>> module"). Anyway, Active Qt and Qt 3D are the 2 "modules" in Qt that
>> have "sub-modules". How should "module" be defined?
>> 
>> One possibility is: 1 module = 1 .pro file entry = 1 DLL (excluding
>> plugins), meaning that "QAxContainer", "QAxServer", "Qt 3D Core", "Qt
>> 3D Renderer", and "Qt 3D Input" are modules, while "Active Qt" and "Qt
>> 3D" are "module groups".
>
>Seems reasonable to me.

Yes, the above is as it should be IMO. Module is a shared library or a QML import. Qtbase is a repository. So Qt3D or QtMultimedia consist of several modules. They are both repositories as well as some sort of funcational unit in Qt. What we're lacking is a good name for the functional unit.

Cheers,
Lars



More information about the Development mailing list