On Fri, Jan 6, 2012 at 12:03 PM, Michael Jeulin wrote:

On Fri, Jan 6, 2012 at 9:17 AM, Miller, James V (GE Global Research) <millerjv@ge.com> wrote:
I am not following the details here. Are you going to Salt Lake? Can we talk about it there?

I am sorry it is not currently the plan for me to go to Salt Lake.

My main interest is keeping all the logic about what is linked and how that is broadcast around to be within the SliceLinkLogic. This keeps it all in one place.

Actually the only difference here and the main idea is to put all the logic in the SliceLogic instead of the SliceLinkLogic; the SliceLinkLogic is in our mind just a broadcaster which forward the information given the "InteractionFlag" (could be a bit analog to a MUX in such way).

I am not sure I understand why it would be better to handle this with a VTK event as opposed to a state on the node.
1) The first advantage of handle this with a VTK event as opposed to a state is to be able to pass data information with the event (e.g. SliceToRASDelta).

2) Then it avoids to Modify() a node, when it doesn't really get modified:

c.f. vtkMRMLSliceLogic::EndSliceNodeInteraction()
...
sliceNode->InteractingOn();
sliceNode->Modified();
sliceNode->InteractingOff();
sliceNode->SetInteractionFlags(0);
...

Where we have gotten in trouble in the past is that we did not have a way to know whether we were in a particular state and hence whether we needed to broadcast a change to other viewers in response to an event. For example, the user modifies a node through the gui, it broadcasts to another node, that node then tries to rebroadcast to the rest of the nodes. Aside from being inefficient, it caused a number of difficult to manage side effects dealing with the order in which operations were applied.

The event mechanism avoids that behavior because it prevents automatic broadcasting. Broadcasting or not is a conscious choice made by the GUI from its internal events (user interaction) and not the state of a node.

Again, this goes back to separating an "Event" from a "Command". The user interaction with a node in an event. In response to that event, the link logic needs to issue a number of commands to the other viewers
There is nothing wrong (except for the few reasons above) to keep the existing design (Interaction + InteractionFlags), however we still need to pass the deltas in a scalable way. Adding a new "temporary" state for each new delta doesn't seem the right way to me. I guess we could add an InteractionDelta that is a vtkVariant type...

I also enclosed the revisited diagram where the last condition has been changed.
Julien, Michael.