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.wilder
parent
404c7cde4e
commit
64df402f84
2 changed files with 23 additions and 1 deletions
Loading…
Reference in new issue