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

Ben Lau xbenlau at gmail.com
Sun Jul 17 19:15:38 CEST 2016

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?


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


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>

More information about the Interest mailing list