Difference between revisions of "AHM2012-Slicer-Architecture"
From NAMIC Wiki
(Created page with '== Modularization Object Specialization == Qt Widgets <- CTK Widgets <- MRML Widgets <- Slicer Widgets vtkObject <- MRMLLogic <- Module Logic == Displayable M…') |
|||
| Line 1: | Line 1: | ||
== Modularization Object Specialization == | == 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 ... | ||
| + | ** ...''represents'' MRML node within a Renderer/RenderWindow. | ||
| + | ** ... handle mouse/keyboard interaction. | ||
| + | ** ... synchronize widget across different views. | ||
| + | |||
| + | * Usually a displayable manager is configured after its associated node(s) have been added to the scene. Later on, if the given node(s) are modified, the displayable manager will react accordingly. | ||
| + | |||
| + | * Each time a viewer is instantiated, this one asks the factory to provide him with a DisplayableManagerGroup. | ||
| + | |||
| + | For that reason, adding a method with the signature like "GetDisplayableManagerGroup()" doesn't "fit" the API. A method like "GetDisplayableManagerGroup(const char* MRMLViewNodeId)" could be added instead. It's also important to note that the factory doesn't have the ownership of the group, it means than a smart or weak pointer should be used. Finally, I would rather prefer the factory remains a factory and doesn't manage groups. | ||
| + | |||
| + | |||
| + | 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 :) | ||
== Views and Layouts == | == Views and Layouts == | ||
Revision as of 07:08, 10 January 2012
Home < AHM2012-Slicer-ArchitectureModularization 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 ...
- ...represents MRML node within a Renderer/RenderWindow.
- ... handle mouse/keyboard interaction.
- ... synchronize widget across different views.
- Usually a displayable manager is configured after its associated node(s) have been added to the scene. Later on, if the given node(s) are modified, the displayable manager will react accordingly.
- Each time a viewer is instantiated, this one asks the factory to provide him with a DisplayableManagerGroup.
For that reason, adding a method with the signature like "GetDisplayableManagerGroup()" doesn't "fit" the API. A method like "GetDisplayableManagerGroup(const char* MRMLViewNodeId)" could be added instead. It's also important to note that the factory doesn't have the ownership of the group, it means than a smart or weak pointer should be used. Finally, I would rather prefer the factory remains a factory and doesn't manage groups.
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 :)
