Definitions

Selection provider: A view which can influence the content of other views by changing its selection.

Selection receiver: A view which depends on the selection of a selection provider and loads its content according to the selection provided.

A selection receiver might be a selection provider the same time.

A view will be hidden in case…

the view is going to be closed,
the view is going to be minimized,
the view as part of a view stack is going to be send to the back, or
the perspective the view belongs to is going to be hidden.

A view will be shown in case…

the view is going to be opened,
the view in a minimized state is going to be restored
the view as part of a view stack is going to be send to the front, or
the perspective the view belongs to is going to be shown.

All notified selections are collected by the SelectionService and put to the selections’ stack. This stack contains all selections notified of all selection providers in a chronological order. Each selection provider is hold only once (with its last selection).

Rules

Selection provider

(1.1) As soon a selection provider notifies a selection it will put on top of the SelectionService’s stack.
(1.2) In case a selection provider is going to be hidden, it notifies a "hidden" selection which causes that the selection provider is removed from the SelectionService’s stack.
(1.3) In case a selection provider is going to be shown it notifies its current selection which causes that the selection provider is put on top of the SelectionService’s stack again.
(1.4) In case a selection provider receives the focus it notifies its current selection which causes that it is moved to the top of the SelectionService’s stack again.

Selection receiver

(2.1) In case a selection receiver is going to be shown it requests the latest relevant selection from the SelectionService’s stack (top down) and if available it loads its content accordingly. If no relevant selection is available the selection receiver stays empty or clears it content when needed.
(2.2) In case a selection receiver clears its content and is selection provider the same time it has to notify an empty selection. This causes the action described in 1.2 .
(2.3) After loading the content a table view (as the selection receiver) selects the first table entry automatically by default. If it is a selection provider the same time it notifies its new selection.
(2.4) As soon a selection receiver receives an empty selection it requests the next relevant selection from the SelectionService’s stack (similar to the behavior described in 2.1 ).
(2.5) As soon a selection receiver receives a "hidden" selection from the current selection provider it requests the next relevant selection from the SelectionService’s stack. If there is no more relevant selection, the selection receiver keeps the selection of the hidden selection provider.
(2.6) A selection receiver only handles a selection if it is shown.
(2.7) In case a selection receiver is linked to a specific selection provider explicitly it ignores all selections coming from other selection providers. As soon the explicit link is removed it picks the latest relevant selection from the SelectionService’s stack (see 2.1 ).
(2.8) In case a selection receiver is locked it ignores all selections and keeps its current content. As soon the lock is removed it picks the latest relevant selection from the SelectionService’s stack (see 2.1 ).

Custom Views

If you create a custom view you should implement you own selection predicate. The selection predicate is used by the GlobalSelectionServiceManager to determine if a selection is relevant for your view. For most detail views the super-class implementation ( EntityDetailModelTableView) of the selection predicate is sufficient. But if your custom view has special rules, which selections are relevant for loading of the view's content, you should implement a specific selection predicate. See as example the implementation of the selection predicate of the view DashboardView. The view should react to selections of three different entity types (Article, StructureGroup and EGD), so we need a selection predicate, which accepts selections of all these entity types:

public class DashboardView extends StdViewPart implements ISelectionListener
{
  ...
  
  @Override
  protected Predicate< ISelection > createSelectionPredicate()
  {
    Predicate articleTypePredicate = new SelectionPredicateFactory.EntityTypePredicate( "ArticleType" ); //$NON-NLS-1$
    Predicate structureGroupTypePredicate = new SelectionPredicateFactory.EntityTypePredicate( "StructureGroupType" ); //$NON-NLS-1$
    Predicate egdTypePredicate = new SelectionPredicateFactory.EntityTypePredicate( "EGDType" ); //$NON-NLS-1$
 
    return new OrPredicate< ISelection >( articleTypePredicate, structureGroupTypePredicate, egdTypePredicate );
  }
 
  @Override
  public void selectionChanged( IWorkbenchPart part, ISelection selection )
  {
    // use selection predicate to evaluate the given selection
    final Predicate< ISelection > selectionPredicate = getSelectionPredicate();
    if ( selectionPredicate.evaluate( selection ) )
    {
      // Avoid unnecessary requests
      if ( !ObjectUtils.equals( selection, this.currentSelection ) )
      {
        this.lastReceivedSelectionPart = part;
        this.currentSelection = ( IStructuredSelection ) selection;
        updateView();
      }
    }
    else if ( part.equals( this.lastReceivedSelectionPart ) )
    {
      // empty selection
      handleEmptySelection();
    }
  }
 
  ...
}

Create three predicates for each of entity types and aggregate them to an OrPredicate. The view will react to any selection of the defined entity types.