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 IPerspectiveFactory. Implementors of IPerspectiveFactory are expected to configure an IPageLayout with information that describes the perspective and its perspective page layout.
One of the main jobs of an IPageLayout 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 IPageLayout and Layout 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 Project Explorer 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 Project Explorer. If the user shows the Bookmarks view, it will appear in the same folder with the Project Explorer, with a tab for each view.
IPageLayout also allows you to define the available actions and shortcuts inside a perspective.
Another valuable service provided by perspectives and the IPageLayout 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 Project Explorer.
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 plug-ins.
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 IShowInSource. Your part can supply its IShowInSource directly using protocol (getShowInSource()) or as an adapter. IShowInSource allows your part to supply a context (ShowInContext) 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 ShowInContext 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 context.
For views, IShowInSource must be implemented by the view in order to offer Navigate > Show In functionality.
You must implement IShowInTarget 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 context.
A target should check the selection in the ShowInContext first in deciding what to show, since this is the more specific information. It should show the input element only if no selection is indicated.
How is the list of available targets determined? You can specify the available targets for your perspective by using the showInPart element of the Perspective Extensions extension point. Recall that a "Show In" navigation may open a view that is not already present in the perspective.