We follow a different way in our plugins. They show which images you are working on, but by labels, not combo boxes. We have not seen problem with this approach, but this does not mean that you need to change the MITK Segmentation plugin if you are happy with it.

I sent a PR:

https://github.com/MITK/MITK/pull/180

It ensures that the highlighting of items in the data manager is consistent with the 'selected' property values.

It will not trigger selection change events in other functionalities / views, because the selection model signals are blocked for the time when the selection is changed in the tree view. I am not sure if it is good, though. I did it to avoid recursion, but maybe other views should still be notified.

I also tried to set the data manager selection through this function:

QmitkAbstractView::SetDataManagerSelection(const berry::ISelection::ConstPointer& selection,
                           QItemSelectionModel::SelectionFlags flags = QItemSelectionModel::ClearAndSelect) const;

but I could not get it work because it would only work if the 'selection' argument is a berry::QtItemSelection, otherwise it does nothing. I have not managed to make a QtItemSelection, though.

Actually I am currently working on a different data manager that allows to specifically set data nodes to a render window, change the view direction etc..
This new data manager offers a selection provider, so that it is possible to send data node selections to all views (QmitkAbstractView).

We are currently evaluating different possibilities of handling more than one data node selection provider and currently it seems to me that your approach is working with another selection provider, as your PR touches only the "selected" property.
We were also thinking about utilizing the "selected"-property in order to synchronize different data selection views across the application.

However, your solution is currently tailored to the data storage tree model and I'd like to discuss, if it is possible to move the PropertyChanged-functionality out of the QmitkDataStorageTreeModel. With the given solution, the PropertyChangedCommand has to be included in a second data manager as well!?

Furthermore, a view subclassing the QmitkAbstractView could also implement the NodeChange-function and set the view model selection according to the given data node selection. This function is called when a data node property has been changed. Unfortunately in this case I don't see any mechanism to find out which property has been changed so it might "reset" a selection, even if another property has been changed (e.g. visibility). Additionally, the block-mechanism you introduced have to be used, though. This has to be done anyway, if we want to combine a selection model in combination with the "selected"-property.

That sounds cool! Is there a prototype already to try out?

It is not related to the original issue, but one thing that I am missing from the data manager is that it can only show the global visibility. It would be nice to provide a way (even if through API) to toggle if the check boxes should control the global or the local visibility (in the active render window of the active render window part if any).

We have an editor that can contain multiple viewers, and I have to map the local visibilities of the selected viewer to the global visibilities and back. Every time when the user selects another viewer, I should set the global visibilities to the local ones in that viewer. Or if the user changes the global visibility of a node by a check box then I have to change its local visibility in the selected viewer. It's been implemented already and it kind of works OK, just I thought to mention in case you are looking for new features or ideas. :)

I really ... khm ... dislike the NodeChange function as it is called too often and you cannot control what events you want to get notified of. The worst is if there is a RequestUpdate in the NodeChange and the scene is re-rendered every time when you select an image. That can slow down the app a lot.

Of course, the PropertyChangeCommand class can be factored out and reused in other classes. In our app we use a more general class called DataNodePropertyListener. You can instantiate a property listener by specifying a data storage and a property name, and you can assign your callback function to this member of DataNodePropertyListener:

mitk::Message2<mitk::DataNode*, const mitk::BaseRenderer*> NodePropertyChanged;

We have it in our core module and found it very useful.