Re: [Evolution-hackers] Beware of GtkTreeRowReference

2011-03-02 Thread Matthew Barnes
On Wed, 2011-03-02 at 09:36 -0500, Matthew Barnes wrote: > > You might use something less "aggressive", like iterator or path, for > > local indexes. > > Won't work in the general case. As soon as you insert or delete a row > prior to the row you're tracking, GtkTreeIter and GtkTreePath are both

Re: [Evolution-hackers] Beware of GtkTreeRowReference

2011-03-02 Thread Matthew Barnes
On Wed, 2011-03-02 at 15:19 +0100, Milan Crha wrote: > Not enough, because the above. I'm doing this [1] (2.91.91+). Search for > e_attachment_store_remove_all() calls (the patch fixes also placing of > attachments to the correct bar). That works, I guess. In other places were I build a hash tabl

Re: [Evolution-hackers] Beware of GtkTreeRowReference

2011-03-02 Thread Milan Crha
On Wed, 2011-03-02 at 08:37 -0500, Matthew Barnes wrote: > Does GtkTreeRowReference drop its model reference when the row is > removed? Hi, it unrefs model when itself is freed, not the row itself (thus the validity check on the reference, I suppose). > If so, it ought to be sufficient to

Re: [Evolution-hackers] Beware of GtkTreeRowReference

2011-03-02 Thread Matthew Barnes
[[I'm CC'ing the hackers list.]] On Wed, 2011-03-02 at 14:00 +0100, Milan Crha wrote: > The GtkTreeRowReference is adding a reference count to the model, so if > you store this GtkTreeRowReference inside model itself, then the model > is never freed. This is a case for EAttachmentStore, if it has