Page MenuHomePhabricator

Refactor plugins to use the new node selection widgets
Closed, ResolvedPublic

Description

With the first versions of the new selection widgets available we could refactor Release-plugins and custom important plugins.

Here is a list of plugins, that rely on image node selection:

plugin nameselection mechanismnoteRelease
BasicImageProcessingQmitkDataStorageComboBox / DataManager selectionNo
Dicom InspectorDataManager selectionNo
Clipping PlaneDataManager selectionused function OnSelectionChanged from AbstractViewYes, part of the Segmentation-Plugin
SegmentationQmitkDataStorageComboBox2 Combo boxes: 1 with an image-predicate, 1 with a segmentation-predicateYes
Segmentation UtilitiesQmitkDataStorageComboBoxseveral mixed combo boxes (with image-predicates / with segmentation-predicates)Yes
MultiLabelQmitkDataStorageComboBox2 Combo boxes: 1 with an image-predicate, 1 with a segmentation-predicateYes
MultiLabel UtilitiesQmitkDataStorageComboBoxYes
ImageCropperDataManager selectionused function OnSelectionChanged from AbstractViewYes
ImageStatisticsDataManager selectionused function OnSelectionChanged from AbstractViewYes
MeasurementDataManager selectionused function OnSelectionChanged from AbstractViewYes
ModelFit and PharmacokineticsQmitkDataStorageComboBox / DataManager selectionNo
MatchPointQmitkDataStorageComboBox / DataManager selectionYes
PropertiesDataManager selectionused function OnSelectionChanged from AbstractViewYes
PointSet InteractionDataManager selectionused function GetDataManagerSelectionYes
RemeshingQmitkDataStorageComboBoxYes
Render Window ManagerDataManager selectionused function 'GetDataManagerSelection'No
Semantic Relationsown selection widget / dialogsimilar to the new selection conceptNo
Volume VisualizationDataManager selectionused function OnSelectionChanged from AbstractViewYes

Related Objects

StatusAssignedTask
OpenNone
OpenNone
OpenNone
Resolvedkalali
Resolvedfloca
Resolvedkalali
Resolvedkalali
Resolvedkalali
Resolved kraeuter
Resolvedkalali
Resolvedkalali
Resolvedfloca
Resolvedfloca
Resolvedkompan
Resolvedkalali
Resolvedkalali
Resolvedkalali
Resolvedfloca
Resolvedkalali
Resolvedkalali
Resolvedkislinsk
Resolvedkalali
Resolvedkalali

Event Timeline

floca triaged this task as Normal priority.May 15 2018, 12:30 PM
floca created this task.
floca added a project: Request for Discussion.

I tagged it with request for discussion to clarify which plugins should be refactored.

For the BlackSwan Project we will at least need the functionality of the

  • Segmentation
  • Segmentation Utilities?
  • MatchPoint: many plugins
    • which are needed? do we provide another, simplified registration plugin that uses match point functionality?
  • Semantic Relations
  • Render Window Manager
  • Properties?
  • new, own PointSet-Tool (with region growing) - from @kleina ?
  • Statistics? Or do we provide our own, new statistics plugin view?

For the BlackSwan Project we will at least need the functionality of the

  • Statistics? Or do we provide our own, new statistics plugin view?

If we can avoid it, I would not use the (refactored) statistics view. With the rework Clemens and André are currently orchestrating, wie should have a solid Basis to do so.

  • MatchPoint

I would refactor all plugins anyways ;)

Some plugins have their UI-classes in a xxUI-modules. From there it is not possible to access the QmitkNodeSelectionDialog since it's located inside the org.mitk.gui.qt.common-plugin. Is there any reason not to move the dialog to the QtWidgets-module?

Edit: The QmitkNodeSelectionDialog depends on the QmitkNodeSelectionPreferenceHelper which itself depends on berry plugins, so it cannot easily moved to the QtWidgets-module.
Do you have any suggestions?

Which xxUI-modules are you refering to?

The reason why QmitkNodeSelectionDialog is in a plugin is that this class makes use of blue berry preferences. To my knowledge blueberry is only available in plugins and not in modules (@kislinsk Please, correct me if I am wrong). Thats also the reason why the selection widgets are in a plugin, because the depend on the dialog.

E.g. SemanticRelationsUI, RenderWindowManagerUI etc., to separate a module's UI logic from other logic.
Yes, I identified the problem, too.

Currently I have a widget inside the SemanticRelationsUI-module, that has buttons to select nodes. These buttons can not open a QmitkNodeSelectionDialog since they cannot access it. Now I need to use a different technique to move the dialog-open-functionality to a corresponding plugin.

kalali removed a subscriber: kislinsk.
floca raised the priority of this task from Normal to High.Jun 17 2020, 6:28 PM
floca added a project: Cleared.

Priority high for all plugins that are part of the release (see table above).

floca added a project: Restricted Project.Jul 6 2020, 9:36 AM