# The difference between Slicer and SlicerCore?
**URL:** https://discourse.slicer.org/t/the-difference-between-slicer-and-slicercore/20327
**Category:** Development
**Created:** [October 24, 2021, 11:49pm UTC](https://discourse.slicer.org/t/the-difference-between-slicer-and-slicercore/20327 "2021-10-24T23:49:02Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@joachim](https://discourse.slicer.org/u/joachim)
#### Post date: [October 24, 2021, 11:49pm UTC](https://discourse.slicer.org/t/the-difference-between-slicer-and-slicercore/20327/1 "2021-10-24T23:49:02Z")
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.
---
### Author:  [@pieper](https://discourse.slicer.org/u/pieper)
#### Post date: [October 25, 2021, 3:01pm UTC](https://discourse.slicer.org/t/the-difference-between-slicer-and-slicercore/20327/2 "2021-10-25T15:01:26Z")
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.
Regarding Core and non-Core see:
[https://doc.qt.io/qt-5/qcoreapplication.html](https://doc.qt.io/qt-5/qcoreapplication.html)
---
### Author:  [@joachim](https://discourse.slicer.org/u/joachim)
#### Post date: [October 25, 2021, 11:42pm UTC](https://discourse.slicer.org/t/the-difference-between-slicer-and-slicercore/20327/3 "2021-10-25T23:42:07Z")
Thanks.
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`).
---
### Author:  [@lassoan](https://discourse.slicer.org/u/lassoan)
#### Post date: [October 26, 2021, 2:54am UTC](https://discourse.slicer.org/t/the-difference-between-slicer-and-slicercore/20327/4 "2021-10-26T02:54:15Z")
> [@joachim](#):
>
> 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?
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.
---
### Author:  [@joachim](https://discourse.slicer.org/u/joachim)
#### Post date: [October 26, 2021, 11:01am UTC](https://discourse.slicer.org/t/the-difference-between-slicer-and-slicercore/20327/5 "2021-10-26T11:01:05Z")
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.
Thanks 🙂