[Qt-interest] Proxy models

[Stephen Kelly]

Kishore wrote:

> On Monday 30 Aug 2010 5:07:43 pm Stephen Kelly wrote:
>> Kishore wrote:
>> > I have been working with proxy models lately and am intrigued by their
>> > complexity.
>> > 
>> > In short, it seems that most implementations of proxies use a QMap that
>> > maps beween QPersistantModelIndex's of the source and the proxy.
>> > Somehow this seems very inefficient o me. Memory consumption would go
>> > very high when the number of indexes increase. It is not uncommon for
>> > say a mail application to have several thousands of indexes and maybe
>> > 2-3 proxies between the view and the actual data.
>> 
>> That's what we do in proxies used kmail, kaddressbook etc, execpt that we
>> use two QHashes, not QMap. Additionally, you don't have to map every
>> index, only the parent indexes, so it's not a huge problem given that in
>> a mail application you'll probably have only a few hundred mail folders
>> (which are the parents).
> 
> In a mail application, every mail that has a reply is a parent. Right?

Yes, my solution to actually turn the list into a tree is not fully thought 
through yet, but it's getting there:

http://steveire.wordpress.com/2010/01/06/testing-proxy-models-gets-easier-
again/

I think there may even in that use-case be ways to lazily create the 
threads. At any rate it will only have to thread one mail folder at a time 
(which could be 20000 or 40000 emails, but still...)

> 
>> We use far more than 4 or 5 proxies too, because you can have
>> multiple tabs with different data and each tab has at least two proxies.
>> 12 at runtime is probably not uncommon. On mobile we don't have tabs but
>> we have more proxies there for navigational reasons. A running
>> kmail-mobile has about 18, though many are often empty or contain only a
>> small amount of data, or do trivial fast mapping.
>> 
>> At any rate, they are not the cause of slowdown.
> 
> Interesting. And as Bo writes, it is not much memory overhead too!
> 
>> QSortFilterProxyModel doesn't use persistent indexes from the source
>> model, which I thought was interesting and annoying because there's more
>> work to do to keep them updated manually.
> 
> Well, indexes will need to be updated by someone right? If it's not the
> proxy, it is the source.

Right, but I was referring to maintenance of the indexes in the code. If you 
store persistent source model indexes they are maintained inside 
QAbstractItemModel, whereas the QSortFilterProxyModel has code for 
maintaining them itself.

> 
>> > Is this design really the best way considering speed and memory? I have
>> > not really seen any other MVC classes for comparison...
>> 
>> Note that you can create mappings lazily. If you have a tree and the view
>> has not expanded everything it won't ask for everything. You can create
>> mappings in your rowCount or hasChildren implementation and only maintain
>> them then.
> 
> Tree models are far more complex than tables and lists when implementing
> proxies! :) It seems quite clearly that maintaining persistent indexes is
> really the most effective solution here.

I think so too. What does your proxy do?

All the best,

Steve.

> 
>> I also don't really know of any comparable MVC APIs, but I had a short
>> look at gtkTreeView, but I don't think that has any proxying concept. I'm
>> sure .NET has some MVC stuff now too, but I haven't looked at it. If you
>> find any let us know.
>> 
>> All the best,
>> 
>> Steve.
>> 
>> > I am getting more and more interested in this and am curious to see
>> > some other MVC architectures! :)