On 17 July 2016 at 19:22, Ola Røer Thorsen <[email protected]> wrote:
> Thank you for the feedback, Ben. > > 2016-07-15 19:32 GMT+02:00 Ben Lau <[email protected]>: > >> 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 > [email protected] > http://lists.qt-project.org/mailman/listinfo/interest > >
_______________________________________________ Interest mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/interest
