We've already seen some ways the workbench allows the user to control the appearance of plug-in functionality. Views can be hidden or shown using the
Window >Show View menu. Action sets can be hidden or shown using the
Window > Customize Perspective...
menu. These features help the user organize the workbench.
Perspectives provide an additional layer of organization inside a workbench
window. Users can switch between perspectives as they move across tasks. A perspective defines
a collection of views, a layout for the views, and the visible action sets that
should be used when the user first opens the perspective.
Perspectives are implemented using
are expected to configure an
with information that describes the
perspective and its perspective page layout.
Workbench part layout
One of the main jobs of an
is to describe the placement of the editor and the views in the workbench window. Note that these layouts are different than the
Layout class in SWT. Although
solve a similar problem (sizing and positioning widgets within a larger area), you do not have to understand SWT layouts in order to supply a
perspective page layout.
A perspective page layout is initialized with one area for displaying an editor. The perspective factory is responsible for adding additional views relative to the
editor. Views are added to the layout relative to (top, bottom, left, right) another part. Placeholders (empty space) can also be added for
items that are not initially shown.
To organize related views and reduce clutter, you can use
IFolderLayout to group views into tabbed folders. For example, the Resource perspective
places the resource navigator inside a folder at the top left corner of the
workbench. Placeholders are commonly used with folder layouts.
The Resource perspective defines a placeholder for the bookmarks view in the
same folder as the resource navigator. If the user shows the bookmarks view, it will appear in the same folder with the
navigator, with a tab for each view.
also allows you to define the available actions and shortcuts inside a
addActionSet is used to add action sets to a perspective.
addNewWizardShortcut adds a new entry to the File >New menu for a perspective.
addShowViewShortcut adds the names of
views that should appear in the Window >Show View menu when the
perspective is active.
addPerspectiveShortcut adds the names of
perspectives that should appear in the Window >Open Perspective menu when
the perspective is active.
Another valuable service provided by perspectives and the
is to aid in navigation between an editor and its related views. We
typically think of views as helping the user find the objects to work with in
editors. However, the converse operation is also useful: a user
working with an object in an editor may need to navigate to that object inside a
view. This can be accomplished using the workbench Navigate > Show
In menu. This command allows the user to jump to one of any number of
related views in the context of the currently edited (or selected) object.
For example, a user editing a file may want to jump over to that file in the
The plug-in architecture of the workbench allows developers to contribute views
and editors in different plug-ins that are not even aware of each other.
By implementing support for "show in," your view or editor can support
convenient navigation to or from the views and editors contributed by other
This navigation allows users to move quickly between views and to easily open a
view that is not usually shown in a particular perspective. For example, a
user working in the Java perspective can use Navigate > Show
In to view the currently edited Java file in the Navigator view.
If you want to allow users to use Navigate > Show In from your
editor or view to jump to another view, you must implement
Your part can supply its
directly using protocol (getShowInSource()) or as an adapter.
allows your part to supply a context (
which is used by the target to decide how to show the source. The show in
context for an editor is typically its input element. For a view, the
context is typically its selection. Both a selection and an input element
are provided in a
to give the target flexibility in determining how to show the source.
A default context for editors is provided, so that your editor can
participate in "show-in" without any special coding. For
editors, the input element and selection are used to create an appropriate
must be implemented by the view in order to offer Navigate > Show In
You must implement
if you want your view to be a valid target for a "show in"
operation. The target is responsible for showing a given context in a
manner appropriate for its presentation. For example, the Navigator view
expands its tree to select and reveal a resource specified in the
A target should check the selection in the
first in deciding what to show, since this is the more specific
information. It should show the input element only if no selection is
Presenting appropriate targets
How is the list of available targets determined? You can specify the
available targets for your perspective in its
Recall that a "show in" navigation may open a view that is not already
present in the perspective. Using
you can specify a valid "show in" target by id. In this way, the
valid targets can be established without unnecessarily creating any views.