Same fix as Stephen Kelly's fix for QIdentityProxyModel in https://codereview.qt-project.org/180390
I tried to write a unittest but QStandardItemModel doesn't support moveRow,
and we don't have all the infrastructure here to force emitting a layoutChange
with specific parents like in the Qt unittests.
This commit, added to the 3 fixes in Qt, fixes crashes when moving folders in kmail.
CCMAIL: steveire@gmail.com
After
int proxyEndRemove = proxyStartRemove;
proxyEndRemove += rc; was adding 0 (empty root)
and then --proxyEndRemove; was making us end up with proxyEndRemove < proxyStartRemove.
REVIEW: 129657
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
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.
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.
The model can be changed after the constructor is run as of Qt 5.5.
At this point, the KLinkItemSelectionModel would still break if that is
attempted, so a unit test comes later.
When the model of the selectionModel is changed, it is necessary to
reset the proxy and clear any selection state.
This amends commit v5.9.0~5 (KSPM: Connect properly to the source model if it
is changed., 2015-03-12)
The proxy would initially say columnCount==0 and would then omit to notify
about the insertion of columns. Simpler to just always have columns, even
when we have 0 rows.
CCBUG: 352369
CCMAIL: steveire@gmail.com
We need to disconnect from a previous source model if present, not the new
one, and we need to be prepared for the new source model to be 0.
REVIEW: 126117
Turns out that there's apparently no overload accepting a QPointer as
the first argument.
This is on Gentoo with qtbase e374ffc29c67493a51527117b55a53dfa5dd4267
and GCC 4.8.3.
Also make sure to tie the lifetime of the connection with `this` because
the lambda accesses our D-pointer, which means that it has to be
disconnected on destruction of `this`. Thanks to Milian Wolff for
catching this.
REVIEW: 123679
Aleix Pol
David Faure
Stephen Kelly
Heiko Becker
Sune Vuorela
Friedrich W. H. Kossebau
Jan Kundrát
Stephen Kelly
Kevin Funk
Andrey Cygankov
Volker Krause
Montel Laurent