gtg-contributors team mailing list archive

[Paul Natsuo Kishimoto <mail@xxxxxxxxxxxxxxxxxxx>]

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...

> 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

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.

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

Cheers,
-- 
Paul Kishimoto
SM candidate (2012), Technology & Policy Program
Massachusetts Institute of Technology

http://paul.kishimoto.name — +19053029315

Attachment: signature.asc
Description: This is a digitally signed message part