Re: Removing and adding headers, letting the view update itself



On Wed, 2006-05-31 at 18:25 +0200, Philip Van Hoof wrote:
> It is now possible to append and prepend items to the header model using
> the TnyListIface. The GtkTreeView will update itself automatically.
> 
> It's not yet bugfree to also remove items. There's something strange
> happening if you remove items starting from the 3th row. I have to check
> what's happening first. I' guessing I'll get this to work soon.

Nothing strange about that! What has something to do with three in a
non-hardcoded piece of code? ;-)

Simple! The very first list node of a doubly linked list! the
"first->next" are two nodes, who are still correct if the first, the
second or the third are removed and if first is copied to a "current"
node. But then "current->next->next" wouldn't be correct anymore.

This is the well known "the behaviour is undefined if you remove an
element from the list while an iterator for it exists" warning most
iterator api's explain.

Well, there's a longer story behind it, like the cached "last_nth" value
I store for optimizing the GtkTreeModel implementation which I had to
correct after removing items, of course. But now it's fixed.

You can now securely remove items from a TnyListIface if that interface
is implemented by the TnyMsgHeaderListModel. The list model can cope
with it by routing the iterator to the first item (which is always
correct if I, after removal, correct the "first" node), and uncaching
the "last_nth" value .. and then telling the view to update itself.
Which will cause a loop over the visible rows.

You can also (still) prepend and append items.

This will make an implementation that implements moving messages from
one folder to another, more easy when speaking of the ui part: Just move
it to the other folder (which you'd have to implement) and tell the
TnyIfaceList to remove the header instance (which already works).


> Also note that I've also tested REUSING the GtkTreeModel instance. As
> long as you only append or prepend, this does work. It's a little bit
> unstable in terms of locking issues ... but I'll get to that.
> 
> -- in some rare cases, you might get a deadly embrace lock if you reuse
> the same model. This probably has something to do with clearing the
> previous set of headers .. while loading the new set of headers.

I thought I knew where to fix this. And it's almost working. So maybe
some other day or minute I'll suddenly see what is going wrong. Please
feel free to in-depth help me investigate what is going wrong.

once this "reusing the GtkTreeModel" works, it proves that the iterator
idea is fully correctly implemented for the header-list type.

> Note that reusing the model will not magically make things a lot faster.
> It's just another way of using the emerging tinymail list types.


-- 
Philip Van Hoof, software developer at x-tend 
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
work: vanhoof at x-tend dot be 
http://www.pvanhoof.be - http://www.x-tend.be




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]