It is possible to share a QItemSelectionModel between two different views, and therefore to share the selection between both. The technique is used in the Chart example and the interview demo.
However, in a complex application, it’s not as simple as a model and a view or two. Eventually someone finds an excuse to add a proxy model, but then you can’t share the selection anymore. If you try it you get a runtime error:
QAbstractItemView::setSelectionModel() failed: Trying to set a selection model, which works on a different model than the view.
The problem is that a QItemSelectionModel operates on one particular model, so views manipulating the selection through it need to be operating on the same particular model. When a selection is made, the indexes which are part of the selection get painted a different colour, so something in the system needs to know of the existence of the proxy model and do the mapFromSource work.
Luckily enough, the designers of the Qt Model View system had the foresight to make some methods of QItemSelectionModel virtual, such as select. That means that when a selection is made through the view, we can do something else than select the indexes, or something supplemental such as a mapToSource call.
The KProxyItemSelectionModel inherits and overrides the QItemSelectionModel methods to encapsulate the concept of "When a selection is made, proxy the selection to another selection model and vice-versa".
It works in both directions, so a selection through either view is forwarded to the other. There is a sufficient amount of voodoo, documented with ASCII art, to allow arbitrary configurations of proxy models to be traversed as long as they share a common source model somewhere along the line.
That’s not the only trick you can play with QItemSelectionModel. More in a later post.
Update: The KProxyItemSelectionModel has been renamed KLinkItemSelectionModel.