← Back to team overview

gtg-contributors team mailing list archive

(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