Page MenuHomePhabricator

Add "context"/scope to data node selection for selection service
Open, WishlistPublic

Description

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.

Remark:
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.

Event Timeline

I had a little chat with Sasha Zelzer about it. He also thinks the propsed way is a sensible and most pragmatic yet scalable way to go.

So to rehash the idea how it now should be implemented:

  1. Introduce a IScopedSelection
class IScopedSelection
{
  public:
    using ScopeType = std::string;
    virtual ScopeType GetSelectionScope() const = 0;
  private:
    virtual ~IScopedSelection();
}
  1. mitkDataNodeSelection implementiert IScopedSelection
  2. Implement a listner/adpater like berry::SelectionChangedAdapter. But in addtion you can define a valid scope. If a selection has implemented IScopedSelection, the selection scope will checked for validity. Only selection with valid scoped (if listner has a scope) will trigger the listner.
kislinsk claimed this task.
kislinsk added a project: Auto-closed.
kislinsk added a subscriber: kislinsk.

Hi there! 🙂

This task was auto-closed according to our Task Lifecycle Management.
Please follow this link for more information and don't forget that you are encouraged to reasonable re-open tasks to revive them. 🚑

Best wishes,
The MITK devs

kislinsk removed kislinsk as the assignee of this task.May 26 2020, 12:05 PM
kislinsk removed a subscriber: kislinsk.
floca removed a project: Auto-closed.