Qt3D-Design-Choices

This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine. Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean.

Design Choices

A list of relevant design choices and various methods used or considered to solve a given feature. There is also a list of failed attempts to remind us of the reason a given method was discarded.

In Use

Qml API based on qmlRegisterExtendedType

We try to expose the same elements from QML as we defined C+. However as we want the core of Qt3D to be independent of the QML module, having extension classes that offer a way to extend our C+ base classes to add QQmlListProperty and other QML specific elements is the best design choice we have agreed on at that point. Until recently we used to have a abstract classes and the C++ or QML would define subclasses based on those. However, that was not as clean as the extension approach mainly because of the multple inheritance that implied.

QChangeArbiter

A mechanism used to have observers monitor observables. In Qt3D's context, backend rendering element can monitor frontend scene elements for updates to adapt the rendering accordingly.

Being considered

QQmlCustomParser

This could be useful for declaring shader uniforms in a quick/efficient QML. This poses a conflict at the moment as a QObject cannot be registered as a custom type and a custom type.

Possible Qt improvements

Move QML types outside of QtQuick

It would make sense to move all element that could be reused by other QML API outside of the QtQuick scope. For instance Qt.vector3d can only be used when importing QtQuick. Also finding a way to have Animations not depend on QtQuick would be nice.