> On 20 Oct 2017, at 12:33, Sean Harmer <sean.har...@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.
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
