Page MenuHomePhabricator

[Selection widgets] Define default for auto selection / listening mechanism
Open, NormalPublic

Description

While refactoring many plugin views to include the new selection concept (single / multi selection widgets with selection service connection) we often had to make the decision if we want to

  • activate auto selection
    • which means that a selection widgets automatically selects a fitting data node if existent
  • listen to selection changes
    • which means that each selection changed event (e.g. inside the data manager) modifies the current selection of the widget

Before introducing the new selection concept, some plugins listened to every selection change (e.g. properties view, pointset view) whereas others needed to be explicitly set to a certain selection (e.g. segmentation, if auto-select was off).

We want to discuss the best default while keeping an eye on the advantages and disadvantages of the two different approaches.

Event Timeline

kalali triaged this task as Normal priority.Jun 23 2020, 1:37 PM
kalali created this task.
kalali renamed this task from [Selection widgetes] Define default for auto selection / listening mechanism to [Selection widgets] Define default for auto selection / listening mechanism.Jun 23 2020, 5:17 PM
kalali moved this task from Backlog to MITK Meeting on the Request for Discussion board.

Result of the discussion:
We will "activate auto selection" mode as default. The user has to select a node anyway. Either the selection slot is empty or already contains an automatically selected node. In both cases the user has to manually select a node. But in the latter case there might be a chance that the automatically selected node is the required one.

We will not "listen to selection changes" as default. The idea of the new selection concept was to have a "local selection concept". We will only enable listening to global selections for specific simple plugins, e.g. PropertiesView, that do not allow any action except displaying some data information.

floca edited projects, added MITK (2020), Restricted Project; removed MITK.Jul 30 2020, 10:47 AM

To finish this task, one should check/verify that all release relevant plugins follow the discussion result.

kalali added a comment.EditedAug 8 2020, 10:00 AM

Plugins from T24775: Refactor plugins to use the new node selection widgets that do not follow the discussion result and need to be refactored:
No auto selection (SetAutoSelectNewNodes(true))

  • Dicom Inspector
  • Segmentation (although it is working if the segmentation plugin is opened AFTER a node has been loaded - but not the other way around)
  • Segmentation Utilities (QmitkDataSelectionWidget) (although it is working if the segmentation utilities plugin is opened BEFORE a node has been loaded - but not the other way around)
  • MultiLabel Segmentation Utilities (QmitkDataSelectionWidget) (not working at all - although the same QmitkDataSelectionWidget is used)
  • Image Cropper (will be fixed in D375)
  • Image Statistics (uses MultiNodeSelectionWidget)
  • Measurement (will be fixed in D372)
  • MatchPoint
  • Properties
  • Semantic Relations
  • Semantic Relations Statistics
  • Volume Visualization

Listen to selection changes

  • Dicom Inspector (but on purpose)
  • Properties (but on purpose)
floca added a comment.Aug 8 2020, 11:56 AM

Just a comment: Image Statistcs uses the MultiNodeSelectionWidget which offers no AutoSelect feature (on purpose, because it could be a lot selections at once...).

I started fixing some plugins. How do we proceed with (ML)Segmentation and MatchPoint?

floca added a comment.Aug 12 2020, 3:21 PM

How do we proceed with (ML)Segmentation

Segmentation already uses AutoSelection as default (can be configured via preferences, default is true)

and MatchPoint?

More tricky, depending on the plugin.

  • Executor: We could autoselect, we don't have a possibility to detect which should be target or moving. Currently I would not do something before we have a good usability concept there.
  • Mapper: We could introduce a auto select for the registration widget. The others to auto select already depending on the registration.
  • visualizer: Autoselect for registration makes sense
  • Evaluator/Manipulator: Autoselect for registratoin makes sense, the image slots have there own implementation for Autoselect already and do not need a change.

How do we proceed with (ML)Segmentation

Segmentation already uses AutoSelection as default (can be configured via preferences, default is true)

Looking at my observed behavior (see comment above) the auto selection feature does not really work in my case with segmentation, segmentation utilities and ml segmentation utilities.
Maybe someone else has time to double-check this, e.g. @thomass?

floca added a comment.Sep 3 2020, 9:57 AM

@kalali It seems that you work at this task and already have some branch. But the task is not claimed by you. Is it on purpose?

Looking at my observed behavior (see comment above) the auto selection feature does not really work in my case with segmentation, segmentation utilities and ml segmentation utilities.
Maybe someone else has time to double-check this, e.g. @thomass?

Just double checked it. As I said the segmentation and ML segmentation view already use auto select and work as they should.
The utility view do currently not autoselect.
I see 2 options:

  1. keep it as is: user has to select manually
  2. activate auto select, where we can ensure sensible selections:
    • Boolean operator: here we would need to ensure that the second slot never containes the same seg then the first slot, so we have to dynamically alter the predicates. But this would lead to a behavior where the user cannot easily swap the slots (because he cannot deselect a slot and he cannot select a data in the other 2nd slot if already selected in the first) -> For now I would not activate autoselect here.
    • Contour To Image: this is a save one for autoselect as both slots have no overlapp
    • Image Masking: same like contour to image
    • Morphological operations: same like contour to image
    • SurfaceToImage: same like contour to image

For ML utilities it is the same.