[Interest] Managing memory with QObject*-models exposed to QML

[Ben Lau]

On 17 July 2016 at 19:22, Ola Røer Thorsen <ola at silentwings.no> wrote:

> Thank you for the feedback, Ben.
>
> 2016-07-15 19:32 GMT+02:00 Ben Lau <xbenlau at gmail.com>:
>
>> Hi,
>>
>> In my humble opinion, QObjectListModel is a bad idea. Because it is
>> difficult to manage the life cycle of QObject with QML. Just like your
>> problem. I have met the similar issue in my first QML project. The
>> application always crashes. The pattern is purely random. I wasted a lot of
>> time to discover the root cause.
>>
>>
> Right. Well it's disappointing if this cannot be solved properly at all. A
> QObjectList is mentioned as a proper model usable in QML so I am tempted to
> say this is a rather big flaw in the QML engine itself.
> http://doc.qt.io/qt-5/qtquick-modelviewsdata-cppmodels.html
> It would be nice to get som kind of confirmation from someone knowing the
> insides of the QML engine, if this is supposed to work or not, and if it
> can be fixed.
>

I want to know the answer too.


>
> Moreover, I am doubt to use a list of QObject as a data storage class.
>> Since QObject is not copyable, it must use a pointer to share QObject to
>> multiple classes. Extra care is needed to manage its life cycle. And they
>> are not able to be passed to another thread for processing directly.
>> Therefore, I always prefer an implicitly shared class over a list of
>> QObject as data storage. It is copyable and thread safe (using a worker
>> model).
>>
>>
> Yes I agree it's not always optimal to use the QObjects. But in the
> application I am working on now it actually makes sense (convenient, few
> lines of code) to use QObjects with properties and especially qml-invokable
> functions.
>
>
>> Instead, I use another approach for sharing data between C++ and QML. I
>> just hold a QList<T> (T is an implicitly shared class) as the central data
>> storage in memory. Whatever it is changed, it will update a
>> QVariabtListModel to inform QML to render the content. However, QML/JS do
>> not write to the model directly. Instead, it will ask another C++ object to
>> update the central data. (e.g by context object / messaging system)
>>
>> In order to simplify the process to update the QVariantListModel, I have
>> written a library called QSyncable. It have document and example code to
>> demonstrate how this approach works.
>>
>> https://github.com/benlau/qsyncable
>>
>>
> This is interesting, I'll try it out. Seems like there is some additional
> overhead of creating the maps and such, but I might not notice.
>
>
yes. There has overhead in converting to QVariantList and finding the diff
(average O(N) algorithm). However, if you just have few hundred of items .
That should be fast enough.


> Is it easy to use additional proxy-models in combination with your library
> to filter and/or sort the lists live, based on updated data in the lists?
>


yes.

As QSyncable also implements the QAbstractItemModel class, it could be used
with other proxy model like QSortFilterProxyModel.

Example:
https://github.com/benlau/qsyncable/blob/master/tests/qsyncableunittests/integrationtests.cpp#L37

However, you may not need a proxy model for QSyncable. Sort & filter could
be done within the convertor function directly.


>
> Ola
>
>
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20160718/fa43caf5/attachment.html>