Re: [Evolution-hackers] Beware of GtkTreeRowReference

[Matthew Barnes <mbarnes redhat com>]

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 table index
for a model (I've been using this pattern for awhile so there's probably
quite a few places), a custom "e_whatever_clear()" function could clear
both the hash table and the model.

It's a shame GtkListStoreClass/GtkTreeStoreClass doesn't have a clear()
method for subclasses to override.  That would at least give us a hook
for dealing with this without having to write our own function.


> 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
invalid.  That's why GtkTreeRowReference exists.