[Kde-pim] More about KRecursiveFilterProxyModel

[Christian Mollekopf]

On Thu, Jan 29, 2015, at 07:30 PM, David Faure wrote:
> On Thursday 29 January 2015 18:31:10 Christian Mollekopf wrote:
> > I guess that is because the fetch state changes (which AFAIK is used for the
> > little spinner).
> 
> Ah, hmm, what a hack. That's a data change that is not a data change...
>  

Typical ETM feature creep ;-)

> > > ETM dataChanged 1
> > > QModelIndex(0,0,0x22488b0,Akonadi::EntityTreeModel(0x1173940) )  "Personal
> > > Contacts" 17:01:12 kmail2(29832)/libakonadi
> > > Akonadi::EntityTreeModelPrivate::monitoredCollectionChanged: collection
> > > changed 6419
> > > 
> > > I know for sure that this collection hasn't changed.
> > > Can't we avoid calling monitoredCollectionChanged when nothing changed?
> > 
> > I'm sure we could optimize this (i.e. by not exposing the fetchstate if it
> > takes less time than n ms), I'm just not sure it's worth it. I think we have
> > bigger performance problems than one additional dataChanged signal per
> > collection.
> 
> One which currently becomes 4+3+2+1=10 :)
> Even with the pending KRFPM patch, it'll still be 4 due to statistics.
> But OK, let's postpone that for now.
>  

Jup

> > > Oh, this is a very good point. I'll try that locally.
> > > http://www.davidfaure.fr/2015/select-optimisation.diff
> 
> I tried it, and wow, things really do seem much faster.
> (and KMail is no longer *always* in that model when I interrupt it in gdb
> - 
> sometimes, but not always).
> 
> Shall I commit it?
>  

Yes please, looks like a nobrainer =)

> > > Another thing I've been trying is to comment out the code in the
> > > dataChanged slot in favoritecollectionsmodel.cpp. I can't see any reason
> > > why this would ever be useful? Favorite collections are recognized by ID,
> > > and an ID doesn't change...
> > 
> > I suppose that's true.
> 
> I'll remove that then. I haven't seen regressions.
> 

+1

> > I don't see it doing any sorting?
> 
> Ah, you're right. I guess the order comes from the underlying model then,
> this 
> being a SelectionProxyModel. So you're right, the underlying stack should
> have 
> the right order. Either that, or we do implement moving favorites around
> and 
> then the favorites model will be responsible for its own ordering. Users
> might 
> like being able to reorder favorites ;)
> 

But on the other hand we don't necessarily need more complexity in a
stack that is already way out of hand ;-)
(on the other hand, in this particular case, adding manual sorting and
thus being able to remove the rest of the model stack arguably reduces
complexity.... feel free to add that if you like)

> > But other than that we could move it down in the stack. We'd loos quota
> > coloring, the rest doesn't really matter as far as I can tell.
> 
> Agreed. Something to keep in mind if we still see too many incoming 
> layoutChanged. But that will require solving the ordering first.
> 

Jup
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/