AHM2012-Slicer-Architecture

Modularization Object Specialization

• Slicer is build on top re-usable and tested libraries.

Displayable Managers

• Displayable manager: Specialized logic handling both RenderWindow <-> MRML and RenderWindow <-> Logic interactions.

• Motivation: Have a well-designed mechanism to ...
  • ...represent MRML node within a Renderer/RenderWindow.
  • ... handle mouse/keyboard interaction.
  • ... synchronize widget across different views.
  • ... avoid to re-invent the wheel again and again.

• Usual scenario:
  • Each time a viewer is instantiated, it asks a factory to provide him with a https://github.com/Slicer/Slicer/blob/master/Libs/MRML/DisplayableManager/vtkMRMLDisplayableManagerGroup.h DisplayableManagerGroup].
  • DisplayableManagerGroup contain a list of DisplayableManager
  • Each DisplayableManager is associated with Renderer + InteractorStyle

• Factories:
  • vtkMRMLThreeDViewDisplayableManagerFactory
  • vtkMRMLSliceViewDisplayableManagerFactory

These factories Indeed, the API is very similar, both the (1)ThreeD and (2)Slice DisplayableManager derive from vtkMRMLAbstractDisplayableManager.

The differences are that:

(1) deals with MRMLViewNode / ThreeDInteractorStyle

(2) deals with MRMLSliceNode / SliceInteractorStyle

And again, the overhead:

- in a term of efficiency should be limited since displayable manager can be registered on demand
- in term of readability should be very low. Indeed, you will have a Annotation base class for ThreeD and other one for Slice DisplayableManager. And it would be very clear to understand which object is responsible to do what ..
- in term of line of code .. is more important ! But considering modern code editor and efficient c++ pre-processor/compiler .. things should go smoothly :)