Calling create_mapping in setSourceModel as introduced by 8455bfee76
can lead to an early call to filterAcceptsRow, and some existing applications may crash.
It is also an incomplete solution since it was only done for the
toplevel index but not for child indexes.
Instead, go back to creating mappings on demand.
This means coming up with a different fix for QTBUG-87781 (dataChanged
not emitted for indexes that haven't been mapped yet, i.e. not queried
or shown anywhere).
When this happens, we can't know if the index was previously filtered
out or not (for lack of a dataAboutToBeChanged signal...). Creating
the mapping with the new data only gives us the new state of affairs,
there's no reference state to compare to. Therefore, when the mapping
is missing (during dataChanged handling), create it, but skip all the
logic about row insertion/removal, just forward the dataChanged signal
if the row isn't filtered out.
Creating the mapping might require creating first mappings for parents,
recursively, which wasn't done anywhere in QSFPM yet, hence the new
create_mapping_recursive() method.
In addition to all this, the handling of removed items was incorrect,
remove_source_items did nothing if the parent was gone, and then
source_items_removed was trying to adjust indexes in an incorrect list.
If the parent is gone, clear the proxy_to_source list, so there's
nothing to adjust afterwards. This bug actually doesn't happen anymore
in this version of the patch, but the change still seems right and might
prevent repeating a long debugging session in the future.
Thanks to ChunLin Wang for the unittest in this commit.
Done-with: ChunLin Wang
Pick-to: 6.1 6.0 5.15
Change-Id: Id543d0cc98f1a03b5852bda01d2f49b980e06be7
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
4ec5622e62