A context can be used to influence what commands are available to the user at any given moment.
Contexts are much more dynamic than activities. While an activity represents a broad set of function that
is available to the user most of the time, contexts describe a focus of the user at a specific point
in time. For example, the commands available to a user while editing text might be different than those
available to a user while editing Java text or browsing packages in the package explorer.
Defining a context
Contexts are declared in the
extension point. Consider the following context which is defined for editing text:
Contexts are assigned a name and description that are used when showing information about the context to the user.
The id of the context is used when binding UI contributions such as commands to a particular context.
Contexts are hierarchical in nature. When a context is active, the commands available in the context and in its parent contexts
are also available. This is useful for defining levels of contexts that move from very general situations down to more
specific contexts. In the context definition above, note that there is an id of a parent assigned to the context:
The parent context defines the more general context of working within a window. Its parent defines an even
more general context of working within a window or a dialog.
Associating a contribution with a context
So far, all we've done is define a hierarchy of contexts. The context becomes useful when it is referenced in the
description of another UI contribution. The most common use of contexts is in key bindings. When a context is
associated with a key binding, the key binding will only be active when the user is in that context. For example,
the following markup specifies the root dialog and window context as the context for a key binding:
Using Context API
The workbench context support includes an API for working with the defined contexts and defining
criteria under which a particular context should become enabled. Most plug-ins need not be
concerned with this API, but it is useful when defining specialized views or editors that define
The starting point for working with contexts in the workbench is
Plug-ins can obtain the global context support instance from the workbench.
IContextService contextService = (IContextService)PlatformUI.getWorkbench()
can be retrieved using an
protocol for getting all defined or enabled context ids, and for getting the associated
for a particular id.
These objects can be used to traverse the definition for a context in API, such as getting the
id, name, or id of the parent context.
Listeners can be registered on the context manager or on the contexts
themselves to detect changes in the definition of a particular context or in the context manager
See the package
for more information.
Contexts can be enabled programmatically:
IContextActivation activation = contextService.activateContext("org.eclipse.ui.textEditorScope");
is a token that can be used to deactivate an active context. You should ensure
that you only activate defined Contexts.
If you are activating a more specific Context within your part (either
View or Editor) you can use the part site service locator to active your Context.
The part's IContextService will take care of activating and deactivating the
Context as your part is activated or deactivated. It will also dispose the
Context when the part is disposed.