Improving the exposure of `vtkSlicerModuleLogic`s to other components

Development
1

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:

  • Each vtkSlicerModuleLogic is created and kept by its corresponding qSlicerModule, as a member variable.
  • A logic object can be obtained by the qSlicerAbstractCoreModule::logic() method or 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 qSlicerModules and vtkSlicerModuleLogics in vtkMRMLApplicationLogic, which is a more reachable component.
  • Remove qSlicerAbstractCoreModule::logic() and 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.

@lassoan, @jcfr, @pieper, does it look to you like a good course of action?

2

Thanks for working on this and for the detailed summary. Beside of one nitpick outlined below, it all makes sense.

  • Remove qSlicerAbstractCoreModule::logic() and qSlicerAbstractModuleRepresentation::logic() . For consistency, the only way to access the module logics will be vtkMRMLApplicationLogic::GetModuleLogic(const char* moduleName) .

I suggest we keep these.

The use of vtkMRMLApplicationLogic::GetModuleLogic(const char* moduleName) should be considered to access module logic from displayable managers/application code/scripts.

And I still think a module Foo should still access FooLogic using the existing accessors.

3 Likes
3

Yes, we shouldn’t remove the old API or we could break extensions. But having this extra non-gui method to access the logics sounds great.

1 Like