Slowly moving functionality to Slicer Core?

[che85]

After talking to @lassoan and @pieper, I would like to slowly move overall useful functionality to meaningful Slicer Core utility packages (e.g. slicer.gui or slicer.qtutil).

@fedorov Do you have any objections to this idea?

We all know, that this process might take time.

[fedorov]

No, I don't have objections. I am supportive of this idea. My main concern is how to support tools that are already using the toolkit. Do you have a plan how to make that transition smooth?

[lassoan]

Overview of existing files in SlicerDevelopmentToolboxUtils and how could be integrated into Slicer core:

https://github.com/QIICR/SlicerDevelopmentToolbox/blob/master/SlicerDevelopmentToolboxUtils/buttons.py
https://github.com/QIICR/SlicerDevelopmentToolbox/blob/master/SlicerDevelopmentToolboxUtils/widgets.py
https://github.com/QIICR/SlicerDevelopmentToolbox/blob/master/SlicerDevelopmentToolboxUtils/constants.py
https://github.com/QIICR/SlicerDevelopmentToolbox/blob/master/SlicerDevelopmentToolboxUtils/events.py
=> Very useful but this kind of low-level infrastructure should be mostly maintained in C++ in CTK or in Slicer core. Some Python-only conveniences could be kept in Python.

https://github.com/QIICR/SlicerDevelopmentToolbox/blob/master/SlicerDevelopmentToolboxUtils/decorators.py
=> We need to discuss each of the decorators one-by-one. Some of them clearly useful, for some of them convenience may not justify the increased opacity of the code.

https://github.com/QIICR/SlicerDevelopmentToolbox/blob/master/SlicerDevelopmentToolboxUtils/exceptions.py
=> These should go to the classes that throw them.

https://github.com/QIICR/SlicerDevelopmentToolbox/blob/master/SlicerDevelopmentToolboxUtils/helpers.py
=> These are all very useful and should be added to appropriate places in Slicer core. Some of the low-level features would be better to be ported to C++.

https://github.com/QIICR/SlicerDevelopmentToolbox/blob/master/SlicerDevelopmentToolboxUtils/icons.py
=> Seems convenient to use but decreases transparency, which may lead to errors. For example, I expect that I can find all references to an icon by searching for its name in the code base. We can use add some of the concepts to scripted module classes to make icons easier to access.

https://github.com/QIICR/SlicerDevelopmentToolbox/blob/master/SlicerDevelopmentToolboxUtils/metaclasses.py
=> It is an interesting proposition that we should discuss. We mostly use slicer namespace for accessing global variables among modules. It is very explicit, but the syntax is not very simple. We should see your use cases, how those are addressed currently using singleton pattern, and what could be the alternatives. Similarly, we should have a look if singleton pattern could improve some of our global variables (slicer.dicomDatabase, slicer.selfTests). We should also consider that infrastructure classes should be easily accessible from C++, too.

https://github.com/QIICR/SlicerDevelopmentToolbox/blob/master/SlicerDevelopmentToolboxUtils/mixins.py
=> There are many useful features in this. We need to go through each to decide where the final place should be.

[lassoan]

Do you have a plan how to make that transition smooth?

Probably we should leave SlicerDevelopmentToolbox as is. Maybe just add optional deprecation messages for methods that are made available in Slicer core as well.