Page MenuHomePhabricator

Refactor plugins to use the new node selection widgets
Open, HighPublic

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
OpenNone
Resolvedfloca
Resolvedkalali
Resolvedkalali
Resolvedkalali
Resolvedkraeuter
Resolvedkalali
Resolvedkalali
Resolvedfloca
OpenNone
Resolvedfloca
Openkompan
Resolvedkalali
OpenNone
Resolvedkalali
Resolvedfloca
Resolvedkalali
Openkalali

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.

kalali added a subscriber: kleina.EditedMay 16 2018, 1:24 PM

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?
floca added a comment.May 16 2018, 4:41 PM

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 ;)

kalali updated the task description. (Show Details)Jun 11 2018, 1:57 PM
kalali added a comment.EditedJun 12 2018, 10:54 AM

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?

floca added a subscriber: kislinsk.Jun 13 2018, 1:00 PM

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 updated the task description. (Show Details)Jun 18 2018, 9:34 AM
kalali updated the task description. (Show Details)Jan 23 2020, 2:54 PM
kalali removed a subscriber: kislinsk.
floca updated the task description. (Show Details)Jan 27 2020, 9:09 PM
floca updated the task description. (Show Details)Jan 29 2020, 9:10 PM
kalali updated the task description. (Show Details)Feb 3 2020, 5:28 PM
kalali updated the task description. (Show Details)Feb 18 2020, 11:20 AM
floca updated the task description. (Show Details)Feb 19 2020, 4:57 PM
floca edited projects, added MITK (2020); removed MITK.Wed, Jun 17, 10:59 AM
floca raised the priority of this task from Normal to High.Wed, Jun 17, 6:28 PM
floca added a project: Cleared.

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

kalali updated the task description. (Show Details)Thu, Jul 2, 9:47 AM
floca added a project: Restricted Project.Mon, Jul 6, 9:36 AM