Page MenuHomePhabricator

Set 'selected' property when using the new selection concept
Open, NormalPublic


Looking at the data manager we find
node->SetSelected(..) in void QmitkDataManagerView::NodeSelectionChanged(const QItemSelection& /*selected*/, const QItemSelection& /*deselected*/).
This sets the selected property of the data node so that other plugins can easily find out if a node has been selected. This is currently used in T25483.
Since we use the new selection concept - also with a focus on a more local selection - we do not maintain the selected property anymore (apart from the data manager).

We should investigate if this property is still needed / used by other plugins and if so how we want to maintain the selected property using the new selection concept.

In MITK$514$456$467$343 and more$476$59$61

For usage inside the LevelWindowManager see branch in this task.

Next steps

  • look through the mentioned classes and find out how the "selected" property is used
  • think about the new selection concept: does the use of the "selected" property make sense with the new local selection concept (nodes can be selected in a plugin instead of the data manager / nodes can be selected in a plugin that has nothing to do with one of the above mentioned classes)
  • see if the mentioned classes are able to be connected with the selection bus (only available inside plugins - blueberry dependent) - as an example see level window manager inside this task (mitk::LevelWindowManager::ServiceSelectionChanged).
  • alternatively think about the consequences if each local selection (widget) of a plugin view sets the "selected" property of a locally selected node - what implications does this have on the above mentioned classes?

Event Timeline

kalali triaged this task as Normal priority.Jan 2 2019, 6:28 PM
kalali created this task.

This would be necessary if we want to use the render window manager with the mxnmultiwidget and the mentioned task (T25483).

This would be necessary if we want to use the render window manager with the mxnmultiwidget and the mentioned task (T25483).

This is only true if we use the old, non local level window widget. We have also differnt other issues with this widget, therefor I would include "skipping it and using other means/widgets for level window interaction" also in our considerations.

I came across this as I re-added the level window slider to the MxNMultiWidget (we didn't include this before as we used the PACS mode inside the MxNMultiWidget - which allows to change the level window via mouse moving). Now our user wants to use the level-window-presets available from the context menu of the level window slider.

OK. But we definetly should talk about it before it is approached.

Another idea would be to use our QmitkSelectionServiceConnector to connect the service bus with a slot of the level window manager / level window widget, such that each selection is noticed by the level window slider and the context menu can access the currently selected data nodes.
I looked into the implementation and I think this is something we can do, given the code that we have.
However, I support the idea of rethinking and redesigning the level window manager (resp. level window widget). There are a lot of conditions and checks which make the class complex and error-prone.

I implemented the service connection idea for the BlackSwan demo and I will test if this is a proper fix (ITO general idea).