You are expected to let your views know whenever any data gets changed. This "letting know" can happen through multiple ways; emitting dataChanged
is the most common one when the structure of the indexes has not changed; others are the "serious" ones like modelReset
or layoutChanged
. By a coincidence, some of the Qt's views are able to pick up changes even without dataChanged
on e.g. a mouseover, but you aren't supposed to rely on that. It's an implementation detail and a subject to change.
To answer the final bit of your question, yes, dataChanged
must be emitted whenever any data returned from the QAIM::data()
changes, even if it's "just" some other role than Qt::DisplayRole
.
You're citing performance problems. What are the hard numbers -- are you actually getting any measurable slowdown, or are you just prematurely worried that this might be a problem later on? Are you aware of the fact that you can use both arguments to the dataChanged
to signal a change over a big matrix of indexes?
EDIT:
A couple more things to try:
Make sure that your view does not request extra data. For example, unless you set the
QTreeView
'suniformRowHeights
(IIRC), the view will have to execute O(n) calls for eachdataChanged
signal, leading to O(n^2) complexity. That's bad.If you are really sure that there's no way around this, you might get away by combining the
layoutAboutToBeChanged
,updatePersistentIndexes
andlayoutChanged
. As you are not actually changing the structure of your indexes, this might be rather cheap. However, the optimization opportunity in the previous point is still worthwhile taking.