[Interest] Any idea why QAbstractItemView::selectedIndexes() is protected?

[André Somers]

Op 3-7-2012 15:48, K. Frank schreef:
> Hi André!
>
> Thank you for the reply and the pointer to QItemSelectionModel.
>
> On Tue, Jul 3, 2012 at 2:06 AM, André Somers <andre at familiesomers.nl> wrote:
>> Op 3-7-2012 1:17, K. Frank schreef:
>>> Hi List!
>>>
>>> I'm wondering why QAbstractItemView::selectedIndexes() is protected,
>>> rather than public.
>>> ...
>> I don't know exactly, but the public API for manipulating selections is
>> QItemSelectionModel. I think the method is there for the convenience of
>> view implementors, but I am not sure. I could imagine it being handy for
>> normal users as well. On the other hand: it does not save you much over
>> using the QItemSelectionModel.
> Yes, QItemSelectionModel looks quite full-featured, so it's probably
> the way to go in general.
>
> I must admit, I'm not really getting the design philosophy behind Qt's
> model / view framework.
>
> For example, QItemSelectionModel gets attached to a model (not a
> view) via its constructor:
>
>     QItemSelectionModel ( QAbstractItemModel * model )
>
> But from its documentation:
>
>     The QItemSelectionModel class keeps track of a view's selected
>     items.
>
>     A QItemSelectionModel keeps track of the selected items in a view,
>     or in several views onto the same model. It also keeps track of the
>     currently selected item in a view.
>
> To me the selection seems very view-ish, so I find myself a little
> surprised that it's mixed up with the model.
>
> Maybe I don't properly understand where Qt draws the boundary
> between model and view.  This is not the first instance where my
> intuition suggests that something is view-ish, but Qt puts it in the
> model.
You are right: selection is a view feature, not a model feature. 
However, the item selection model still needs access to the model to 
have an idea of what items there are at all. For that, it will need a 
pointer to the model in any case. It could potentially get that from a 
QAbstractItemView, but other than the model it doesn't need anything 
from the view. Why not construct it using a pointer to the model 
directly then? That gives you the opportunity to use (abuse?) the class 
in other ways too, if you want. For instance, I have used 
QItemSelectionModel to keep track of a single boolean flag for each item 
once in a proxy model class.

Keep in mind that views _have_ an item selection, but they are not quite 
bound to them. The current design makes it possible, for instance, to 
easily share the item selection between two or more views by simply 
setting the same QItemSelectionModel on multiple views.

André