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

[Ola Røer Thorsen]

Hi Jan!


> 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?
>
>
Yes. When deleting, I basically do this:

(m_objs_ is a QList<MyObject*> )
int rm_idx; // the index to remove

m_objs_[rm_idx]->deleteLater();
beginRemoveRows(QModelIndex(), rm_idx, rm_idx);
m_objs_.removeAt(rm_idx);
endRemoveRows();

I verified that the object is deleted "later".


> > 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 delegate is alive for a short period after this, it seems. I guess
maybe just another event loop cycle? I didn't investigate it further yet
though.


> 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).
>
>
The "MyObject" class is a QObject for various reasons, I have some other
objects of the same type that aren't stored in this list. So it looked like
a decent solution. But I guess it's a bit outside the normal use of the
model/views.

I don't instance that many of them (5-10) so the performance seems decent
enough.

Thanks for the feedback,
Ola
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20131218/3c43b3d7/attachment.html>