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

[Stephen Kelly]

Arnold Krille wrote: 
> Interesting how your explanation against my reasoning just proves my
> point... In akonadi you can not simply attach a view and get all the info.
> I tried. You need your special proxies and special views. 

Great. Thanks for trying it out. I'm not sure what you tried, what you expected and what happened, but I'd be interested to know. Might be off topic for this thread though, so an off-list email would be fine if you prefer. You should have gotten all the info you needed. It might be that the docs are just out of date on how to do it.

But, yes, depending on what you are trying to achieve, your use-case could  need different proxies. For example if your 'core' model is something like:

(*)
- Foo1
- - Bar1.1
- - Bar1.2
- - Foo1.1
- - - Bar1.1.1
- Foo2
- - Bar2.1
- Foo3

Ie, Foos can contain other Foos, then you're lost with view.setRootIndex(), because in you view which is supposed to only show 'Bar' objects the result will be:

Bar1.1
Bar1.2
Foo1.1

You don't get any opportunity to filter out the nested Foo object. By using the 'special' SelectionProxyModel, you can pass the result through a QSortFilterProxyModel and get a view with just 

Bar1.1
Bar1.2

Note how this is example is analogous to a tree of mail folders containing emails. The only other way I can think of is having a custom view which watches for new Foo objects in the model, and does 'View::setRowHidden()' on them. That seems like a very ugly solution because it puts your filtering rules in the view.

> (And then
> special conversions and data-types, which was where I didn't go on yet.)
> So why did you even use standard-models? You could have done that with
> your own model-proxy-view classes, no need to use the ones from qt.

I have to say, I never even considered this :). The Qt stuff is almost just what I wanted. If I were to roll my own solution it would only be a bad imitation.

> 
> Using custom roles to show the additional columns is just bad. If it is a
> fixed number of say 20 columns, it means 20(!) custom roles. If its a
> variable number of columns, you are lost...

I'm not convinced that having 20 custom roles is automatically a bad thing, but it's not necessary anyway.

QVariant MyModel::data(const QModelIndex &index, int role) const
{
  EmailObject emailObject = mapToSource(index).data(EmailObjectRole);

 switch(index.column())
 {
 case 0:
  return emailObject.subject();
 case 1:
  return emailObject.sender();
 case 2:
  return emailObject.date();
// etc.
 }
}

Having a configurable number of columns is also not a problem. It's just a case of  if (shouldShowSender){...}, returning the correct columnCount, and emitting the right signals when it changes.

> 
> Using a proxy to hide unneeded columns is way easier. And stays compatible
> with just attaching standard views without special proxies.

*Shrug*. There's nothing special about the proxies or views that I use. Intermediate proxies are sometimes needed for your use case. It's an entirely standard way to consume the Qt Model View framework AFAIK. There's nothing special about the view I use either. Attaching a regular QTreeView to the core akonadi model or any of the proxies should work just fine.

At any rate, I think the OP has enough information to make his own analysis/decision. Maybe we'll just disagree on how best to use the framework.

All the best,

Steve.

> 
> Have fun,
> 
> Arnold