After
int proxyEndRemove = proxyStartRemove;
proxyEndRemove += rc; was adding 0 (empty root)
and then --proxyEndRemove; was making us end up with proxyEndRemove < proxyStartRemove.
REVIEW: 129657
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.
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
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
The KSPM should never clear or reset the selection of the
QItemSelectionModel it refers to. It should be a read-only view on
that selection. If the selection changes while the source is being
reset, ignore that selection change. The proxy will clear its own
cached data when it processes the modelReset signal from the model,
and will populate itself with the selection as it is at that point.
since qtbase commit ebef2ad1360c80ad62de5f4a1c4e7e4051725c1c
"Make the empty Q_ASSERT still check its argument for validity" the
build shall fail.
REVIEW: 121562
FIXED-IN: 5.7.0
BUG: 342872
It looks like Qt4 emitted layoutChanged in circumstances where Qt5 emits
rowsMoved. This could be used to optimize things, but for now we just
act the same way in either case (rebuilding the mapping).
REVIEW: 117777
This is the beginning of revision history for this module. If you
want to look at revision history older than this, please refer to the
techbase wiki for how to use Git history grafting. At the time of
writing, this wiki is located here:
http://community.kde.org/Frameworks/GitOldHistory
If you have already performed the grafting and you don't see any
history beyond this commit, try running "git log" with the "--follow"
argument.
Branched from the monolithic repo, kdelibs frameworks branch, at commit
162066dbbecde401a7347a1cff4fe72a9c919f58
Kevin Funk
Stephen Kelly
David Faure
Heiko Becker
Friedrich W. H. Kossebau
Stephen Kelly
Andrey Cygankov
Jan Kundrát
Hrvoje Senjan
Alex Merry
Jenkins CI