Page MenuHomePhabricator

Create a connector class to make data storage viewers be able to provide and receive global data node selections
Closed, ResolvedPublic

Description

A concrete implementation of the proposed base widget, which serves as an API for different data storage viewer implementations, should be able to provide and receive its own data node selection to and from other data storage viewers, in order to communicate a workbench-wide data node selection.
Since a data storage viewer will be embedded in a workbench view (AbstractView), it can use the existing selection service to send and receive data node selections on the global selection bus.
However, in order to separate the responsibilities, we propose to create a connector-class, that allows to set a data storage viewer instance as a global selection provider / receiver. A plugin-developer is free to use this connector-class to extend a data storage viewer instance.
If the connector-class is used, the signal/slot mechanism of the base widget is employed to send/receive selections on the selection bus. If the connector-class is not used, the signal/slot mechanism works only locally inside its embedding workbench view.

Event Timeline

check mitk::DataNodeSelection and QmitkDataNodeSelectionProvider

kalali renamed this task from Connect the base widget with a selection service to Crate a connector class to make data storage viewers be able to provide and receive global data node selections.Nov 20 2017, 12:32 PM
kalali updated the task description. (Show Details)
floca renamed this task from Crate a connector class to make data storage viewers be able to provide and receive global data node selections to Create a connector class to make data storage viewers be able to provide and receive global data node selections.Nov 23 2017, 4:42 PM

I see following options/inspirations for the implementation:

  1. Inspiration by QmitkDataNodeSelectionProvider. This covers only the firing of the selection events. But its a start. In addition one would need to extend the interface of the storage viewer base to also expose a QtSelectionModel (but this would also open up more usage options. And as soon as context is included, we have to derive/extend the QmitkDataNodeSelectionProvider to also support sending selections with a special context.
  1. As you already mentioned a signal/slot based interface.

I managed to get a first version working.
There are more tests and investigation needed, as my basic test plugin does not cover filtered views or multiple berry-views.
However, single- and multi-item selection is correctly propagated, if the user has checked the checkbox (checkbox to set a viewer as a selection provider). The viewers also set their selection according to the standard data manager view.

kalali raised the priority of this task from Wishlist to Normal.Dec 21 2017, 1:20 PM

I changed the design:
For changes concerning the base widget (now an abstract model), see T23749.

A new QmitkModelViewSelectionConnector-class now accepts the model-view-pair that is used inside a widget to serve as a data storage viewer. This model-view-pair is now used by the selectionConnector-class to transforms, receive and propagate selections (e.g. selection changed signals).
This still fits the description of the task. However, there is no data storage viewer anymore but just a model-view-pair.
Also, the local selection handling has been moved to this selectionConnector-class (additionally to the global selection handling via the selection bus).

I split the 'QmitkModelViewSelectionConnector' into a 'QmitkModelViewSelectionConnector' and a 'QmitkSelectionServiceConnector'. The later is used to connect with the workbench-wide selection bus. The first is used to provide access to the model-view pair to receive / send selections via the signal-/slot-mechanism