On Mon, 09 Aug 2010 10:41:25 -0400, Paul Natsuo Kishimoto <[email protected]> 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 _______________________________________________ Mailing list: https://launchpad.net/~gtg-contributors Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg-contributors More help : https://help.launchpad.net/ListHelp
