gtg-contributors team mailing list archive

[Lionel Dricot <ploum@xxxxxxxxx>]

Hello,

(for the impatients, I need your brain when there are asterisks ****)

This weekend, I replaced signals calls by callbacks in liblarch. For
inner stuffs, there's some place where it doesn't make sense to use
signals (such as between the TreeView interface and the FilteredTree
because there's always a 1<->1 relationship).

In other places, it make sense to use signals so I make it optional.
Without signals, we can at least have proper traceback of crashes and it
has proven to be really useful (already fixed a bunch of random crashes
when adding children).


So far, I've been able to write two new tests and solve a few bugs. Now,
when loading the liblarch branch with a complex set of data, you are
more likely to encounter three types of crashes. (this is with the
direct TreeModel. I disabled sorting for now)


1) Exception: 5@1 has no parent but is not in VR  (this is a
FilteredTree.py exception in liblarch itself)

I really want to understand what happens there and write a test for that
particular case. This is clearly a liblarch bug. Without signals, the
trace is very clear but I still don't understand of we can go in such a
situation.


2) gtk crashes. "There is a disparity between the internal view of the
GtkTreeView, blabla"

So far, I've been able to identify that this happen always (at least on
my laptop) after next_node() returned None because the node was at the
end of the VR (next_node() should return None if there's no next_node).
(so, for a given set, it always happen for the same node). What is funny
is that it will not always fail !  next_node() always return None for
that specific node but, sometimes gtk accept it, sometimes not.

I'm wondering if this could be due to the fact that VR is an unordered
list but that, in next_node, we consider it as ordered (using the index
of the node. It means that it is possible to have a VR [aa,bb], to
remove aa the reinsert it and have [bb,aa] after that. In fact, it is a
problem for every node as the children are unordered.


3) ** (gtg:21955): CRITICAL **: pygtk_generic_tree_model_get_value:
assertion `VALID_ITER(iter, tree_model)' failed

No idea what is it. I think it happens only when requesting the value of
column 3 for the tags but I'm not sure.


4) segmentation fault. Without anything more. That's clearly a GTK bug
(or a pygtk one). 

(did I said 3 ? There was 4)


***************************
***** Ok, now I need your brain.

I have a theory to explain why it is such a pain to implement the
TreeModel. All those problems only happen at start (or mainly).

Imagine building a tree:
a
b
-> c
d

1. Liblarch start to build the tree. It is in the state where a and b
were added.

2. At this point in the launch process, the ViewTree is connected to
gtk.TreeModel.

3. It means that the TreeModel start to parse the tree (which is usally
a get_nth_child(None,0) but it depends). It discover a.

3b. At the same time, node are still added. So the TreeView receive a
"node c" added. But of course, b was still not discovered.


Do you think it might be a root cause for the problem ? Is it possible
that we missed something regarding this ? (or that the GTK developpers
missed that ?)


Need thinking about that,


Good night,


Lionel