[Development] QML and QAbstractListModel

[André Somers]

Op 14-1-2013 11:07, Alberto Mardegan schreef:
> On 01/14/2013 09:29 AM, André Somers wrote:
>> I am not fan of this change. I think the API of QAIM is already very
>> complex. Adding more methods that basically only sort-of mirror existing
>> methods but for a more confined use-cases only makes that situation
>> worse. For instance, you now get a count() method that claims that it
>> returns the number of items in the model. What does that mean in the
>> context of a tree model?
> I added the property (and the new get() method) to QAbstractListModel,
> not to QAbstractItemModel.
I am sorry, I overlooked that.

Still, I think the argument is still largely valid: you're introducing 
double API into an already complex (some may say: overly complex) API. 
And, if the code is in QAbstractListModel, you can still only export 
models based on that to QML and rely on these properties to be 
available. Is that really useful? Wouldn't table models need to be 
exported too, even if you could only get the first column that way? 
Event tree models might be useful to display in a flat list. At least, I 
have found myself displaying a tree-type model in a QListView on more 
than one occasion, thus ignoring all further columns and child nodes.

>
> [...]
>> Perhaps an alternative approach would be to create a proxy model for
>> exporting to QML. It could include all the methods you need, but it
>> would not complicate QAIM itself.
> [...]
>
> That might be the best approach, yes. But I wonder if we should target
> tree models or just list models. The API for tree models might be
> significantly more complex (exporting QModelIndex to QML might not be
> trivial).
No, I don't think it would be trivial to create such a mapping. But I 
don't think it would be needed to be a useful helper class to get models 
into QML.

Even if it only works for the top level nodes of trees, it would still 
be (IMHO) a solution that is preferable to your solution. It would work 
for all other models, including things like lists that have a QSFPM on 
top of them. Note that you can also use a proxy to map a table model to 
a list by mapping the data in columns to different roles. The base class 
would not be a QListModel, but the data would be available from the 
first column anyway. When using the proxy approach I suggest, that works 
nicely. Your approach only works for models that derive from 
QAbstractListModel directly.

André