[Development] [Interest] [Qt3D] Mixing C++ and QML

[Shawn Rutledge]

> On 20 Oct 2017, at 12:33, Sean Harmer <sean.harmer at kdab.com> wrote:
> 
> Hi,
> 
> On 19/10/2017 19:44, Shawn Rutledge wrote:
>> 
>> What exactly do you think should be done there, in case we can fix it
>> some day?
> 
> Probably something like how NSObject manages properties of collections. So far with Qt3D we've only needed the same level of semantics as offered by QQmlListProperty - or rather we've worked within those constraints. So a simple indexed container with the ability to add/remove items.
> 
> In a more general setting I can easily also imagine support for associative containers too.

We have dynamic properties at least.

> The tricky part will be deciding which semantics do we wish to support and where do we draw the line between such properties and recommending to use a full-blown model instead.
> 
> Speaking of which, improving QAIM to be able to return data for contiguous blocks of indices in one function call would be a really welcome addition. Calling so many virtuals to retrieve a single data value for a single index and role is not exactly efficient. The existing QAIM API is fine for the existing views but doesn't scale well when trying to use them to populate, say a buffer of per instance data on a large scale. Yes I know we could avoid this with custom API but users have so many models at this point it would be nice to offer some interoperability with them.

So you want something like QVector<QVariant> dataRows(const QModelIndex &startIndex, int rows, int role = Qt::DisplayRole)?

It’s been pointed out as somewhat of a bottleneck (for QtQuick applications at least) that data() returns QVariant.  But what sort of alternative is there for C++ API?

>> A typical pattern in QtQuick is that a QQmlListProperty is the
>> default property, so declared children are automatically added.  But
>> instead you have to declare the Components first, and then also add
>> them to a vector.  Why is that?  It seems needlessly cumbersome to
>> me.  If Components are naturally always children of Entities,
> 
> ^ that is your broken assumption. Components do not have to be children of the entity. We actually started out with that but found that it prohibits sharing components which can sometimes be handy.

“sometimes”… so maybe add declared child Components to the vector automatically, but also allow sharing them by ID when necessary?

> Also whilst I'm here, there's an annoying limitation in the QML language that prevents mixing inline declaration of elements with elements referenced by id in a list property. That is you cannot write something like:
> 
> Mesh { id: mesh }
> Material { id: material }
> 
> Entity {
>    components: [ Transform {}, material, mesh ]
> }

Is there a bug written up about that one?

>> If you think there’s something wrong with the normal QObject
>> parent/child relationship, then there’s another mechanism for
>> detecting declared QML “children" and doing “something special” with
>> them.
> 
> Do you mean the autoparent callback?
> 
> http://code.qt.io/cgit/qt/qt3d.git/tree/src/quick3d/quick3d/qt3dquick_global.cpp#n676
> 
> We need this here because it's not enough for us to know that the parent is a QObject. We need to know if it's a QNode to be able to add the new child to the scene.

OK, it calls setParent but does not add it to the components vector.

> One possible future solution we discussed with Lars and Simon for this is to make QObjectPrivate::setParent() virtual.

Yeah that might work, but has a pervasive cost I suppose.