1berry/qtbase
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update model-view documentation about layoutChanged

Browse Source 
This has always been true, but hasn't been documented well enough, so
triagers are giving incorrect information in bug reports (eg QTBUG-47711
and QTBUG-53221). That incorrect information is being treated as truth
by Qt users which take action based on incorrect information. That is a
problem, so try to make the documentation clear.

Change-Id: I4e44a9a0675cdd7d9289ec209ae32d5a92899fc9
Reviewed-by: David Faure <david.faure@kdab.com>
This commit is contained in:
Stephen Kelly 2016-12-18 11:32:27 +00:00
parent 7c402ad3d1
commit 7adfe7494b
1 changed files with 16 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
src/widgets/doc/src/model-view-programming.qdoc
View File

@ -2070,9 +2070,22 @@
Normally, the begin and end functions are capable of informing other components
about changes to the model's underlying structure. For more complex changes to the
model's structure, perhaps involving internal reorganization or sorting of data,
it is necessary to emit the \l{QAbstractItemModel::layoutChanged()}{layoutChanged()}
signal to cause any attached views to be updated.
model's structure, perhaps involving internal reorganization, sorting of data or
any other structural change, it is necessary to perform the following sequence:
\li Emit the \l{QAbstractItemModel::layoutAboutToBeChanged()}{layoutAboutToBeChanged()} signal
\li Update internal data which represents the structure of the model.
\li Update persistent indexes using \l{QAbstractItemModel::changePersistentIndexList()}{changePersistentIndexList()}
\li Emit the \l{QAbstractItemModel::layoutChanged()}{layoutChanged()} signal.
This sequence can be used for any structural update in lieu of the more
high-level and convenient protected methods. For example, if a model of
two million rows needs to have all odd numbered rows removed, that
is 1 million discountiguous ranges of 1 element each. It would be
possible to use beginRemoveRows and endRemoveRows 1 million times, but
that would obviously be inefficient. Instead, this can be signalled as a
single layout change which updates all necessary persistent indexes at
once.
\section3 Lazy population of model data