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
KSelectionProxyModel listens to two delegate objects for changes: the
source model of the proxy, and the selectionModel. When a QModelIndex
which is selected gets removed, slots connected to signals for both
clients are executed. Whichever slot is executed first updates the
KSelectionProxyModel, and when the other slot is executed it ignores the
already-handled event.
Until Qt 5.5. QItemSelectionModel required the model to be passed in its
constructor. Prior to commit v5.9.0~21 (KSPM: Make the
setSelectionModel method public., 2015-03-08) the KSelectionProxyModel
required the selectionModel to be passed in its constructor.
Because the order of slot execution follows the order of signal slot
connection, the KSelectionProxyModel slot for handling deselection was
always executed first to process the removal.
Since Qt 5.5 and KItemModels 5.9.0, it is possible to set the model on
the QItemSelectionModel and the selectionModel on the
KSelectionProxyModel in a different order, meaning that the
(before/after) slots for handling removal of a row from the source model
is executed first. When the before slot is executed the selectionModel
still has a selection, but by the time the after slot is executed the
selection has already been removed (because QItemSelectionModel updates
its selection on rowsAboutToBeRemoved).
Remove the check for the selection being empty in the after slot to
handle this case.
l10n daemon script
David Faure
Sune Vuorela
Friedrich W. H. Kossebau
Andreas Cord-Landwehr
Olivier CHURLAUD
Stephen Kelly
Jan Kundrát
Stephen Kelly