[Qt-interest] Question about Models, Roles and data

[Stephen Kelly]

Andre Somers wrote:
>> For the table that shows all the data fields of all the bars, you may
>> need to build a new model (so, the answer changes to two, sorry!), as
>> you would be changing parent/child relationships here.

I don't agree here. You can use a proxy to flatten the tree into a list, and
then use another proxy to filter out everything but the bars.

See http://api.kde.org/4.x-api/kdelibs-
apidocs/kdeui/html/classKDescendantsProxyModel.html

and how it is used in for example trunk KAddressBook:
http://websvn.kde.org/trunk/KDE/kdepim/kaddressbook/mainwidget.cpp?view=markup

>> > Is the general rule of thumb that I need one model
>> > per data class per view type?  Or can I play around with custom roles
>> > to reduce the number of model classes I need?

You don't need one model per data class per view type. You can use custom
roles and proxies on top of a 'core' model.

>> You should be able to get almost everything you want from a single model.
>
> And stay away from custom roles unless you really have to use them.
>
> The main advantage of model-view is that you can plug (almost) any view on
> any model and it makes sense, preferable without using custom delegates.
> If you need custom roles, you loose all that...

This isn't true. Custom roles allow you to use proxies transparently. You
can do someIndex.data(MyCustomRole).value<MyCustomObject>(); and it doesn't
matter if 'someIndex' came from the 'core model' or one of the proxies. This
doesn't really have anything to do with views.

Regarding having different representations with different numbers of
columns, I'd say rather than creating a 'core' model with 20 columns and
then hiding the ones you don't want, make it have only one column, and
implement proxies to have different numbers of columns, and fetch the data
from the core model using custom roles. That way you don't have to instruct
the view to hide things, because there's nothing extra there in the first
place.

I did roughly that for Akonadi, and it's quite flexible. A possible problem
point is that you'll have to make the headerData come from the proxies
instead of the core model. I solved that using a custom role hack because I
needed full flexibility, but if you really only have foos and bars, it's
probably not a big deal to have that in two proxies.

All the best,

Steve.