Tried observing the modified event on the layout node, but it's getting a slice node modified event after that and it's not working quite right.

Using these steps to reproduce:
download sample data MRHead
Place a fiducial on the red slice
Right click to zoom and move the slice, fiducial moves correctly.
Switch to red slice only layout, fiducial position is okay
Switch back to conventional layout, fiducial position is wrong in red slice viewer.
If I then update the conventional view red slice with right click and drag, the fiducial gets updated.

Digging into the code, the position does get updated, but it's not reflected in the slice viewer. I'm seeing two calls to OnMRMLSliceNodeModifiedEvent that call UpdatePosition, but only the first call is resulting in a changed position. The second call sees the position of the seed widdget in screen space and the fiducial mrml location in display coordinates as teh same.
I suspect that using the slice nodes to differentiate the widgets for each viewer might be failing when a second red slice viewer has been created - I think the red only one is the one that's getting updated invisibly, while the conventional view red slice viewer is seeing the same widget and not updating it's position for a different FOV. When I explicitly change the view on the conventional layout slice node via right click and drag, the fiducial displayable manager correctly updates the fiducial positoin. I'm still trying to confirm this, then to fix it.

Re: last note: don't think I have the root cause, I think now that it's due to multiple calls to UpdatePosition because both OnMRMLDisplayableNodeModifiedEvent and OnMRMLSliceNodeModifiedEvent are called when the layout changes, but when the user does a right click and drag, I only get OnMRMLDisplayableNodeModifiedEvent triggered.

Happens with fiducial and ruler, but not ROI (linux64 debug build).

Fiducial and ruler worked fine on my Mac.

Setting a priority on the events observed in the annotation displayable managers may help. Try setting the priorities low, e.g. -1, so that all the everything else receives the events before the annotation. This may ensure that the SliceNode and window geometry are synchronized before the annotation display coordinate is updated.

I had to put a priority on the MoveEvent in the CrosshairDisplayableManager to get the crosshair to display reliably in the Slice Viewers other than the one being interacted with. In my case, the Crosshair RAS was being updated before other Slice Nodes were updated, so the logic would turn off the Crosshair since it was not "on" the current Slice. Setting the crosshair priority low, the SliceNode would update its position before the Crosshair responded to its change in position.

I've been looking into this. The annotations displayable managers respond to slice node modified events, but that's set up in the superclass with no priorities. Seeing if I can get at the observer and adjust the priority on it after the manager is registered.

You could add a priority ivar to the superclass that uses the default value. Then in the subclass, initialize the ivar from the superclass so that when the observers are added they would use the new value.

Doesn't seem to have fixed the problem this problem.

ENH: Easier re-use by adding static sliceView DisplayableManager "Convert" methods

See r21245 / http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=21245

The double calls to OnMRMLDisplayableNodeModifiedEvent are caused by the method
qMRMLSliceControllerWidget::setSliceViewSize
calling ResizeSliceNode on the vtkMRMLSliceLogic. That very properly does a Start/End Modify around setting the FOV and Dimensions on the slice node, but the problem is that when EndModify is called, it triggers a modified on the slice node which triggers another call to UpdateMatrices which triggers a modified again (I think).
There's also an issue that there are two paths of modified events happening when the layout is changed and the new widgets are shown:
ctkVTKSliceView::resized
is also triggering modified events.

Since working on Mac, which will do the bulk of RSNA demos, retarget for 4.3

Test checked in as svn 22587:
http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=22587
(the test passes even when it shows the wrong fid location, so as to keep the dashboard green while I continue to debug the problem)

The following topic is solving the problem:

 https://github.com/jcfr/CTK/tree/slicer-1914-fix-ctkVTKSliceView-resize-event

Now improving the proposed solution to attempt to fix 0001690

Fixed in r22938
See http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=22938

Tested the 2014-03-14 nightly build on Linux and it's fixed there. Running the FiducialLayoutSwitchBug1914 test:
Difference between starting and ending seed display coordinates = 0.980968
Mean of image difference = 15.9848
Image difference is too great!
Expected <= 5.0, but got 15.9848

The fiducial was placed at:
33.4975, 79.4042, -10.2143
mousing over, it doesn't visually move, but checking in the Markups module, the position at the end of the test is:
33.934, 79.408, -10.214

The test when run on my Mac nightly build from the command line is still reporting a difference in starting and ending fiducial display coordinates:

564: Starting seed display coords = 162, 14, 0
564: Fiducial starting position
564: Red Slice only
564: Conventional layout
564: Ending seed display coords = 156, 15, 0
564: Fiducial ending position
564: Difference between starting and ending seed display coordinates = 6.57724
564: Display coordinate difference is too large!
564: Expected < 1.0 but got 6.57724

Added a further check to the test (and have it fail on the dashboard properly) to compare RAS positions if display positions are not close enough (resetting the layout can change the FOV):
http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&amp;revision=24251