Re: [Gtk2hs-devel] TreeList stuff

[Axel S. <A....@ke...>]

On Thu, 2006-03-30 at 15:40 +0100, Duncan Coutts wrote:
> On Sat, 2006-03-25 at 16:59 +0000, Duncan Coutts wrote:
> > On Sat, 2006-03-25 at 16:31 +0000, Axel Simon wrote:
> 
> > > ** (a.out:21223): CRITICAL **: gtk2hs_store_ref_node: assertion `iter-
> > > >stamp == store->stamp' failed
> > > 
> > > Is that part not yet finished?
> > 
> > Right, with the tree store we get lots of that. With the list one it
> > should be fine.
> > 
> > It's because in the tree implementation, customStoreIterNthChild should
> > return information for the top level of the tree when the mIter is
> > Nothing. Currently it returns False instead.
> 
> So here's the debug output:
> 
> ** (treetest:17730): DEBUG: calling gtk2hs_store_iter_nth_child (0xa6cac0, 0x7fffff89ddd0, (nil), 0)
> 
> So the view is asking for the 0th row at the top level.

Uhm, I think I tried to fix that by changing getTreeIterLeaf, which
didn't work correctly on top-level. So I get:

** (a.out:29722): DEBUG: calling gtk2hs_store_get_iter
(0x91e3ea8, 0xbfc18e78, "0")

** (a.out:29722): DEBUG: return  gtk2hs_store_get_iter          =TRUE

> ** (treetest:17730): DEBUG: return  gtk2hs_store_iter_nth_child =FALSE
> 
> and we're returning False which is wrong. After this the view appears to
> do something wrong by asking to ref a node when that iter is invalid.
> However I think that it's our fault for giving the view an inconsistent
> view of the model.

Yes, that was certainly a bug, but...

> ** (treetest:17730): CRITICAL **: iter->stamp == 0              store->stamp == 313933654
> 

This is what I think makes it break at the moment: We return prematurely
in the query functions because the time stamps on the iterators is
incorrect. So, I'd like to fix the time stamps before I look any further
(although I had found the problem last WE AFAIK).


> ** (treetest:17730): CRITICAL **: gtk2hs_store_ref_node: assertion `iter->stamp == store->stamp' failed
> 
> As for the stamps when we are passing iters back to the view update
> signals, couldn't we do that in C too? We could just extract the right
> timestamp from the model and set that in the iter.

Can we? Doesn't that mean we would have to intercept functions like
treeModelRowChanged that actually emit the signal?

> Is there any case where we need to check the iters that are passed to
> treeModelRowChanged (and the other view update funcs) ? In both your
> tree store and the simple list store we're not using iters for the users
> view of updating the model so the user can't get that wrong.

Yes, I think that should be true. I come to think of TreeIters as being
really annoying. The only reason for using them is that marshalling to C
and back is a bit cheaper.

> If we had a store which did use TreeIters in it's user facing interface
> then we'd need to be able to check them.

Yes, but we can probably avoid making TreeIters public except for
CustomStore implementors.

> So how about I just make treeModelRowChanged (and friends) accept iters
> with any timestamp and have it get set correctly. It'd mean their types
> would change from:
> :: TreeModelClass self => self -> ...
> to
> :: TypedTreeModelClass self => self row -> ...
> 
> because we'd need to access the underlying Gtk2HsStore to get the
> current timestamp. But I think that's ok, these are only for custom
> model implementations anyway.

Ok.

Axel.