How to indicate that hasChildren() has changed when using lazy population?

[Coises]

But I'm not really sure I understand your problem. If you do not have any childitems for a particular parent item, then hasChildren() will always return false. Do you want to have it return true if there are no children?

Yes; in fact overriding QAbstractItemModel::hasChildren() to return true even though QAbstractItemModel::rowCount() returns 0 is exactly what one does to implement lazy population. (The documentation is less than clear on this, but experiment showed me that QAbstractItemModel::rowCount() must return 0 until the rows are actually inserted, following the call in QAbstractItemModel::fetchMore() to QAbstractItemModel::beginInsertRows() — which does itself call QAbstractItemModel::rowCount() and must see 0.)

This all works as it should. The problem I can’t seem to resolve is what to do when the status of an unpopulated parent changes such that it no longer has children; or when the status of an item that previously did not have children changes such that it does, but information about the children should not be retrieved and added to the model until required. Debug statements suggest that QTreeView calls QAbstractModel::hasChildren() when it first shows an item, but nothing I can do in the model, short of removing the item and adding it back again, seems to make it call that function again and update the presence or absence of the expansion icon accordingly.

In the user interface of the QTreeView, collapsing and expanding the item’s parent seems to do the trick; and once the item is populated (QAbstractItemModel::fetchMore() is called) there is no problem. The problem is in switching between childless and unpopulated states.

[wysota]

The problem I can’t seem to resolve is what to do when the status of an unpopulated parent changes such that it no longer has children;

I would emit layoutChanged() or dataChanged() for the parent in question.

[Coises]

I would emit layoutChanged() or dataChanged() for the parent in question.

Thank you, Wysota! A single layoutChanged() after a batch of changes appears to work perfectly.