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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Mailing list: https://launchpad.net/~gtg-contributors Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg-contributors More help : https://help.launchpad.net/ListHelp
