The purpose of this post is to frame the discussion around improving the exposure of
vtkSlicerModuleLogics to other Slicer components (e.g., displayable managers). After having a look at the code, my understanding of the current situation is as follows:
vtkSlicerModuleLogicis created and kept by its corresponding
qSlicerModule, as a member variable.
- A logic object can be obtained by the
qSlicerAbstractModuleRepresentation::logic()(for module widgets).
vtkSlicerModuleLogics are very flexible components and it is desirable that they can be more easily exposed to other components (possibly in other modules).
The plan for improving the exposure of
vtkSlicerModuleLogics could be as follows:
- Keeping an association between
vtkMRMLApplicationLogic, which is a more reachable component.
qSlicerAbstractModuleRepresentation::logic(). For consistency, the only way to access the module logics will be
vtkMRMLApplicationLogic::GetModuleLogic(const char* moduleName).
- Lifecycle of
vtkSlicerModuleLogics will still be managed by
qSlicerModules. There will be only 1 logic per module.