On 12/06/15 16:59, "[email protected] on behalf of Sean Harmer" <[email protected] on behalf of [email protected]> 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
