View Issue Details

IDProjectCategoryView StatusLast Update
0001743Slicer4Core: Base Codepublic2017-09-27 12:26
ReporterfinetjulAssigned Tofinetjul 
PrioritynormalSeverityfeatureReproducibilityN/A
Status acknowledgedResolutionopen 
Product VersionSlicer 4.0.1 
Target VersionbacklogFixed in Version 
Summary0001743: Redesign the link mechanism
Description

Hi Jim,

Given the previous email exchanges and all the information, we worked on a solution based on the "anonymous payload mechanism".
We agree that the SliceLinkLogic does not have to manage the Link/HotLink information and there is no more need for vtkMRMLSliceNode::Interacting (which can be deleted).
We suggest the SliceLinkLogic to listen an InteractionEvent and automatically broadcast only depending on the InteractionFlag and the possible (void*) callData (e.g. RASDelta for the MultiPlanarReformat flag).

The SliceLogic will either Invoke the InteractionEvent or not through the SliceNode with its own logic as you can see in the simplified enclosed diagram.
When the user interacts with the widget, the displayable manager computes the "delta transformation" (SliceToRASDelta) from its current coordinate frame to the new coordinate frame:

1) Widget[StartInteraction]->
DisplayableManager->sliceLogic->StartSliceNodeInteraction(InteractionFlag) // In Link mode the Manager saves the initial state of the widget
2.a) Widget[Interaction]->DisplayableManager->SetSliceNodeValue(X)
2.b) DisplayableManager->sliceLogic->Interaction(void) // Invoke or not the Interaction event with the given call Data (e.g. step delta computed by the manager)
3) Widget[EndInteraction]->DisplayableManager->sliceLogic->EndSliceNodeInteraction(void
) // The manager computes the final modification (e.g. final delta) and the interaction flag is reset.

The main idea is to trigger the broadcasting with VTK event instead of a MRML node property.
Concerning the optional "temporary" value, we found that it has to be stored within the Displayable manager as it computes the delta (final and step ones) as well.
Please see the enclosed Diagram for a better understanding.

This solution is similar in the case of the GUI input events instead of the 3D view and will be exactly the same using the SliceCompositeNode instead.
Please let us know what you think about this solution and do not hesitate if you have any suggestion or comment.

Regards.
Michael, Julien.

Additional Information

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.

TagsNo tags attached.

Activities

2012-02-22 07:05

 

LinkLogicDiagramv1.2.png (24,723 bytes)
LinkLogicDiagramv1.2.png (24,723 bytes)

Issue History

Date Modified Username Field Change
2012-02-22 07:05 finetjul New Issue
2012-02-22 07:05 finetjul Status new => assigned
2012-02-22 07:05 finetjul Assigned To => Michael Jeulin-L
2012-02-22 07:05 finetjul File Added: LinkLogicDiagramv1.2.png
2012-08-20 11:50 jcfr Assigned To Michael Jeulin-L => finetjul
2012-08-20 11:50 jcfr Target Version Slicer 4.2.0 - Feature freeze Sept 1st 2012 => Slicer 4.2.5
2012-08-21 09:39 jcfr Target Version Slicer 4.2.5 => Slicer 4.3.0
2013-08-09 04:39 finetjul Target Version Slicer 4.3.0 => Slicer 4.4.0
2014-05-13 11:04 jcfr Target Version Slicer 4.4.0 => Slicer 4.5.0-1
2014-05-13 12:50 jcfr Status assigned => acknowledged
2015-11-02 11:58 jcfr Target Version Slicer 4.5.0-1 => Slicer 4.6.0
2016-10-12 15:12 jcfr Target Version Slicer 4.6.0 => Slicer 4.7.0
2017-09-27 12:26 lassoan Target Version Slicer 4.7.0 => backlog