The application is divided into two parts: Slicer and SlicerCore; qSlicerApplication is a subclass of qSlicerCoreApplication, and qSlicerAbstractModule is a subclass of qSlicerAbstractCoreModule.
What is the intention behind this division? Could it be that Slicer is the GUI version of SlicerCore? This seems strange since qSlicerCoreApplication is a subclass of QGuiApplication. And qSlicerAbstractCoreModule - the foundation for Slicer modules - has actually a method ::widgetRepresentation().
And, if Slicer is built on top of SlicerCore, why is qSlicerCoreModule a subclass of qSlicerAbstractModule? Maybe the naming is wrong and misleading?
All these abstractions by subclassing makes me dizzy.
Yes, there’s a lot of code to parse. In general we try to follow the design and coding conventions of the parent classes, so QSlicerX typically inherits from QX and vtkSlicerX from vtkObject ultimately.
OK, so the division of Slicer into Slicer and SlicerCore is actually an attempt to split Slicer like a Qt GUI and a Qt Core application? So SlicerCore is the “non-GUI version” of Slicer? This seems a bit strange since qSlicerCoreApplication is a subclass of QApplication - Qt with GUI, but I guess it is difficult to do it different.
qSlicerAbstractCoreModule - the parent of all modules in Slicer and part of SlicerCore - has a method ::widgetRepresentation() which returns a qSlicerAbstractModuleRepresentation* . I guess this type (inside SlicerCore) is meant to be an abstraction for something living outside SlicerCore, and ultimately inside Slicer (as a qSlicerWidget : public QWidget).
It is more than an attempt. GUI and non-GUI classes are strictly separated throughout the entire application. It is not two separate versions of the application, but a dependency tree. Non-GUI classes (such as in QTCore, module logics, MRML, displayable managers) don’t depend on any GUI classes (such as in QTGUI, module widgets) and can be used without GUI.
For example, you can create a scene, instantiate some MRML nodes and module logics and use Slicer module features without ever creating a GUI or using Qt at all. Most non-GUI tests work like this.
We don’t see much practical use of it other than having overall cleaner architecture. But in the future we may see significant benefit from this separation. For example, we plan to release non-GUI classes, such as MRML library, SegmentationCore, module logics (and maybe later GUI classes as well) as pip-installable Python packages that can be used without instantiating an application at all.
So the division into Slicer and SlicerCore is done in order to make it possible to use Slicer as non-GUI application. The “Core” in SlicerCore is meant to be Qt Core functionality.
The fact that the class qSlicerCoreApplication depends on Qt with GUI, and qSlicerAbstractCoreModule has a method ::widgetRepresentation(), didn’t make this obvious, but I can see how it works now.
