gtg-contributors team mailing list archive

[Lionel Dricot <ploum@xxxxxxxxx>]

On Mon, 09 Aug 2010 10:41:25 -0400, Paul Natsuo Kishimoto
<mail@xxxxxxxxxxxxxxxxxxx> wrote:
> On Mon, 2010-08-09 at 00:59 +0200, Lionel Dricot wrote:
>> ***************************
>> ***** 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.
> 
>    Is this a MainTree, or a FilteredTree? "Add" seems to mean different
> things in each...


You cannot add a node to a FT because a FT is only a view of a Tree
(called MainTree in the implementation).
Thus, a and b are added to the maintree.

> 
>> 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 ?)
> 
>   In MainTree.new_relationship(), both you and I have a comment asking
> why "toreturn" or "success" is True for a pending relationship.
> 
>
http://bazaar.launchpad.net/~gtg-user/gtg/liblarch_migration/annotate/head:/GTG/tools/liblarch/tree.py#L174
>
http://bazaar.launchpad.net/~gtg-user/gtg/liblarch_rebased/annotate/head:/GTG/tools/liblarch/tree.py#L208
> 
> ...this causes the modification signals to go out for *both* the parent
> and child, even if the child (node c) is "dangling" (i.e. has no parents
> yet, still waiting for them).
> 
>   In FilteredTree, similar things happen: FilteredTree.__adding_loop()
> acts specially when displaying a node that has parent(s) that WILL BE,
> but are NOT YET displayed. It puts the node (e.g. node c) back into the
> queue, to be dealt with later once the parent(s) (node b) are displayed.
> 
>
http://bazaar.launchpad.net/~gtg-user/gtg/liblarch_migration/annotate/head:/GTG/tools/liblarch/filteredtree.py#L490
>
http://bazaar.launchpad.net/~gtg-user/gtg/liblarch_rebased/annotate/head:/GTG/tools/liblarch/filteredtree.py#L759


That's very good ! I found the same problem myself and corrected it today.
I'm curious to hear your opinion on rev. 959 which solves a lot of liblarch
bugs. (best of all is that I added tests for those bugs). In fact, liblarch
itself hasn't been crashing once since that and, for the first time, I
loaded the -s bryce dataset ! (with a bunch of GTK errors, of course).

It looks like, now, there's only GTK errors to correct.
> 
> There are, as I see it, a few ways to deal with this:
>      1. The API docs should make it very clear that when the node-added,
>         node-modified signals etc. are emitted, that does not
>         necessarily mean the MainTree or FilteredTree underneath is
>         "finished". The ID argument of the node-added or node-modified
>         signal may refer to a node that is still "missing" parents.
>         "Missing" means either not displayed (ViewTree on FilteredTree)
>         or not existing at all (ViewTree on MainTree). Then the onus is
>         on any code that uses liblarch to understand this and be
>         prepared to deal with it.
>      2. Add a boolean argument to those signals named "complete" or
>         "pending" or something, that would indicate when one of these
>         odd situations is happening. This is basically like #1, but you
>         are giving liblarch-based code more help to identify special
>         cases.
>      3. Block the signals at some point (probably in ViewTree) if the
>         parents are missing.

Thanks for the input ! I choosed 3. and it seems to work well. In fact,
when I add a node, I block all signals related to that node until the node
is fully added. Simpe and efficient. 

> 
> Not being familiar with the GtkTreeView/liblarch_gtk side of things, I
> don't have any sense of which is best.
> 

That's an ugly part, I admit ;-)

Please continue to read the code that way. That's very useful for me and I
think you start to have a good insight on what happen.

Cheers,

Lionel