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

In T25804#185436, @kalali wrote:

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.

Pushed new branch T25804-Level-window-manager-as-selection-service-listener.

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