[Interest] Best practice for properties, QAbstractListModel with a QList<QObject*> and a Quick2 view

[Jan Kundrát]

On Wednesday, 18 December 2013 11:59:15 CEST, Ola Røer Thorsen wrote:
> However I get problems when I delete objects from the list model. The
> delegates are deleted later than the actual objects, so I get warnings 
from
> QML on the console (saying myObject is null). These seem harmless enough,
> but I would like to avoid having any warnings at all.

When working with the QAbstractItemModel, items can only be deleted via 
resetting the model, or when removing rows/columns. The row/column removal 
shall happen in three phases:

1) call beginRemoveRows
2) remove the internal representation, freeing the MyObject instances
3) call endRemoveRows

I will argue that if a delegate is alive after the beginRemoveRows 
finished, then the QML view is broken. The view shall react to 
rowsAboutToBeRemoved and kill any delegates in response to that signal.

However, you absolutely must not free your internal representation prior to 
calling beginRemoveRows. Are you sure that this is not the case?

> Item {
>    id: theDelegate
>    property string someValue: myObject ? myObject.someObjectValue : ""
> }
>
> but this is just ugly.

Something is apparently picking up some signal which causes the delegate to 
notice that the value of "myObject" has changed. What signal is it? Are the 
delegates alive even after rowsAboutToBeRmoved is emitted?

> The alternative is to create roles for every property in MyObject, and
> connect signals for every one of them so the model updates when one of 
the
> properties changes. Perfectly doable of course, but it has to be kept
> up-to-date with the properties in MyObject, and feels like duplicating a
> lot of code.

It's interesting that you've solved the problem of too many roles by using 
a QObject instance within the model itself. I wonder whether this is 
actually a good path -- QObjects are rather heavyweight, so it is a 
question whether you gain anything by trading the disadvantage of "got to 
call the model's data() too many times, once for each role" by another 
problem, "got to manage expensive QObjects instead of some liteweight 
internal nodes".

Perhaps it fits the rest of the code and using QObjects "inside" the model 
makes sense. However, if that was not the case, simply emitting 
dataChanged() when any "property" changes migth be even easier (and would 
elliminate the need to use properties and separate signals in the first 
place).

With kind regards,
Jan

-- 
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/