[Qt-interest] QAbstractProxyModel methods index, parent, rowCount, columnCount not implemented?

[Stephen Kelly]

Andre Somers wrote:

> Perhaps you are right that using model->index(0,0,sourceIndex); would be
> better, but there is no error there. Just above, I check if the number
> of rows is bigger than 0 (and that would be an error already). At least,
> I /think/ that calling rows() on a model with an invalid QModelIndex
> returns 0, right? 

Nope. Calling model->rowCount(QModelIndex()) gives you the number of top 
level rows.

>> I'm still surprised there's no better way using things like
>> QItemSelection etc to achieve what you're trying to do, though I've never
>> attempted to implement the 'partially checked nodes when 1 or more
>> children are checked' or related features.
> I used a QItemSelectionModel on an earlier attempt. That one was limited
> to lists and tables for exactly this reason: you can only store a
> boolean (selected or not selected) in such a model. To work efficiently,
> I needed something more flexible. As you can see, I am storing two
> four-valued states for each node in the store now (not for each checked
> node per se though).

The old axiom of 'All problems in computing can be solved with additional 
layers of proxy models' can be replaced with 'All problems in computing can 
be solved with additional instances of QItemSelectionModel'.

You can use multiple QItemSelectionModels to describe different things. I 
created an example which doesn't do the things you're doing, but just marks 
things as tristate if a descendant is checked. It's robust to the layout 
changing but needs extra slots for moves and removes of checked items and 
for layout changes. 

http://quickgit.kde.org/?p=scratch%2Fskelly%2Ftricheckable.git&a=summary

It has the advantage of not inventing new api to query it using 
triStateProxy->tristateSelectionModel()->contains(index) and you get change 
notificiations by connecting to triStateProxy->tristateSelectionModel()-
>selectionChanged().


I'd take a similar approach to solve your issue, but the user interactions 
around tricheckable stuff in trees makes my head hurt.


>> Nothing else jumped out to me as something that will break in an obvious
>> situation, but I don't really like the API of creating and passing in
>> QModelIndexLists.
> I am open to suggestions for an alternative. This is the only way I
> could come up with that allows getting multiple lists of indices
> efficiently (short of methods where you are forced to pass in multiple
> lists at once). Changing the API to just /return/ such a list would
> result in the situation where the state can change in between the calls
> (as was the case in the previous version). The user is free to abuse the
> returned QModelIndexLists, of course, but there is little I can do to
> stop that. Note that even QItemSelectionModel has API that returns such
> lists, so that class is just as vunerable if not more so than this one.
>> There's also (unlikely I guess) ways to break it like this maybe:
>>
>>      CheckableProxyModelState&state = m_checkProxy->checkedState();
> That doesn't compile. The versions to circumvent the immediate use of
> CheckableProxyModelState I could come up with all result in compilation
> errors, but perhaps I am not creative enough and someone will come up
> with one what does compile anyway.

You're right. I'm sure I tried to compile it the last time and it worked, 
but now it doesn't...

> 
>> Finally, it looks like you could use a string template system in
>> MainWindow::selectedItemsChanged :)
> :-)
> I guess I could. Suggestions? ;-)
> I actually thought about it, but decided that would be too heavy for
> simple example like this.

Yeah, I agree with you for small this small stuff. Sort of :)

Cheers,

Steve