If the row being removed from the source model isn't shown by KRFPM,
it's correct that we don't need to emit any signals, however we still
need to tell our base class QSFPM so that it updates the mappings
of the visible siblings below that removed row.
Testcase: deleting the Last Search folder in kmail
(full integration test for this testcase will be added to mailcommon).
REVIEW: 128428
BUG: 349789
FIXED-IN: 5.25
This was broken by astyle in commit v4.95.0~5 (Code reformatted using
kde-dev-scripts/astyle-kdelibs. Use git blame -w 5d4c2df to show
authorship as it was before this commit., 2013-12-18), because despite
the filenames, this is not really c++ code.
The KSelectionProxyModelPrivate::beginRemoveRows method is responsible
for figuring out the range in the proxy which is to be removed as a
result of removal in the source model.
There are some trivial cases which were made overcomplicated by the old
code. The complex bit is figuring out the interaction with the
top-level. I suspect that can be simplified further.
The tests are not as rigourous as possible as they only really check
rowCount changes. However, this is usually enough to ensure internal
consistency in the class, and the attached ModelTest should ensure the
rest.
Iterate over the m_rootIndexList and remove things from it based on the
deselection, rather than looping over the deselection and trying to
figure out how it applies to the m_rootIndexList.
Previously, the model would create a mapping for the wrong index while
processing removal. Constrain the re-creation of the mapping by
determining at AboutToBe-time whether to re-create it. This is
important because the mapping contains QPersistentModelIndexes to the
source model, and when post-processing the removal, that is already
invalidated.
BUG: 352369