Currently if you work with DataNode selections the only level of distinction is per "part". So you can request selections from specific views or editors. But if you have sevaral "types" of selections (e.g. view selects the mask and the image) you cannot differentiate.
Basic idea for a simple solution would be
- Extend mitkDataNodeSelection to allow the specification of a contex-id-string.
- Implement a selection listener/adpater (see berry::SelectionChangedAdapter) that can be set to filter for selections to fit a certain context (e.g. by id equality or matching a RegEx) and only trigger for selctions in the right context. (Additional (nice to have) idea: we could define an interface for context. Selection classes can implment this interface to support that feature. That would allow a mor generic adapter not only coupled to DataNodeSelections.
I think we should explictly stress/define "context" as orthogonal to parts. Thus with context you do not encode the origin of the selection in terms of which view/editor (there we have the part ID), but we encode the meaning/purpose (so context/scope) of the selection.
I context ID might have the plugin id in it (e.g. "org.mitk.matchpoint."target_mask), but this then serves more as a namespace of the context definition (e.g. because this plugin was the first to define the context) rather then the part as an origin.