What are the disadvantages of QAbstractListModel containing objects in QML?

Question

Qt offers the ability to combine C ++ models with QML and offers three approaches in documents :

• QStringList
• QObjectList
• QAbstractItemModel

The two previous ones are extremely easy to use, for example. QObjectList :

 // in C++ QList<QObject*> dataList; dataList.append(new DataObject("Item 1", "red")); // in QML ListView { model: dataList delegate: Text { text: name } } 

but both of them have a strong warning:

Note. There is no way for the view to know that the contents of the QList has changed. If the QList changes, you must reset the model [...]

QAbstractItemModel difficult to use with objects because the properties of objects are not directly affected, so keeping them in sync requires a lot of effort.

However, you can wrap the QList in a QAbstractItemModel and get a super-simple model. See Here: Implementation 1 , Implementation 2

---

Is there a reason why Qt doesn't implement this natively? Representation? Problems with memory management? It seems like such a good idea, and with ObjectModel they already implement something similar.

Answer 1

The only noticeable drawback of using QObject as an element of the model is that the base class is quite large, it is a kind of “object-god” (which is an anti-template), which contains a lot that you do not need most of the time. As a result, it has about 160 bytes of "overhead" on top of any model data you may have. This can be problematic if you have a large model with a large number of items, and the elements themselves are relatively small. As a result, you have a lot of overhead.

A QObjectList as a model is always a bad idea unless you are doing something completely trivial. Since it does not implement the proper interface for notifying you of links to change views, the only way is to force update, which will redraw the entire model each time, not just the changes.

There are no requirements for objects of objects if you correctly implement the model.

The second implementation is especially useful for a number of reasons:

• You don’t need to worry about implementing a specific “static” model with fixed roles for each use case.
• the elements of your model can have fundamentally different properties, you are not limited to the "scheme" model.
• you automatically get binding notifications in QML, as you deal with QObject and Q_PROPERTY
• you can define models in declarative, and you can even set models to create tree structures that you cannot do with ListModel .
• you can define the actual model elements in pure QML without recompiling all the time, aka rapid prototyping, and when that is done, you can just port the objects to C ++
• at the same time, in addition to all the advantages, the model is actually much easier to implement and maintain than the usual “rigid” model, the role search is faster, since you essentially have one object role and there is no search, there is no need to implement data change signals for roles etc ... easy peasy