gtg-contributors team mailing list archive
-
gtg-contributors team
-
Mailing list archive
-
Message #00296
(no subject)
Lionel, could you explain when, why and by who signals are emitted in
liblarch? I'm a bit confused.
Let's take the case of adding a node to a parent node. From what I understood:
- we start from the Tree (add_node function), which just passes the call to
MainTree
- we are in MainTree.add_node:
- we call node.set_tree(), which recreates all tree pending relationships
(I haven't figured out why)
- the "relationship" is created and kept as pending (to avoid race conditions)
- we add the node to the list of nodes of the tree
- the pending relationship is updated to be no more pending
- we execute the "added" callback for the new node. A comment
says that the "added" callback will take care of executing the
"modified" callback for the parent (which, from rev. 1040 on, doesn't
work anymore).
- the "added" callback is caught by the filtered tree. This, puts it in a
queue of signals (so that signal callbacks are not executed concurrently)
- when its turn comes, it calls FilteredTree.__add_node
- this first does something with the node parents (which is not clear to me),
then, through a callback, calls the viewtree, which emits the signal
node-added-inview.
- that goes into liblarch-gtk that should be just a thin layer around the
tree.
Is this correct? I haven't found where the modified signal for the parent
should be emitted.
Thanks in advance for the explanation :)
Luca
ps: tests are broken (no modified signals are sent). That's what I was trying
to fix.
Follow ups