Programming the Eclipse Workbench
What makes Eclipse applications most easily recognizable is the Workbench. It is the foundation of applications such as the Eclipse IDE — the main window contains menus, toolbars, and a variety of smaller windows, some tiled, some stacked behind one another. What makes each Workbench application unique is what these windows are and what functionality they provide.
In the previous installment of the Eclipse series an Eclipse Workbench "view" was used as the host of a JFace and SWT components, but I did not go into much detail about its structure or function. In this article, the Eclipse Workbench will be explored in more detail. Specifically, the Workbench "parts" — the views and editors that make up most Workbench applications — will be reviewed.
When you run a typical Eclipse Workbench application, such as your Eclipse IDE, you get the familiar application window with menu and toolbars at the top, status bar at the bottom, and one or more views in between. Many of these views allow you to manipulate the information they present, and perhaps edit it in specialized editors. While some tasks may be implemented as step-by-step wizards, the telltale sign of a workbench application is the ability to view and manipulate information in a variety of ways.
In this article, a simple editor is developed that lets you edit lists of strings stored in plain-text files. A JFace viewer is used to display the model. Menus are provided to allow for the addition of new entries into the list and deletion of selected entries. Also provided is support for undoing, redoing, and saving of these modifications.
To compile and run the example, you will need Eclipse SDK 3.1, available at http://www.eclipse.org/downloads. Some familiarity with the Plug-in Development Environment, JFace, and SWT is required.
From a user's point of view, the Workbench is a top-level application window (or several of them, in fact) with menus, toolbars, views, and editors. While this is by no means a requirement, many users have actually come to expect certain menus and views to be available in Workbench applications; for example, there is usually a File menu that allows for creation of new and opening of existing files, an Edit menu with editing actions such as Cut, Copy, and Paste, as well as a Window menu for customizing some aspects of the user interface.
From a developer's perspective, the Workbench serves as the foundation for applications that contribute their views, editors, wizards, and other components as plug-ins. You can look at the Workbench as the infrastructure that you can use to build a certain class of desktop applications. In fact, Eclipse started out as an IDE workbench suitable for developing integrated development tools, but over the years it evolved into a generic platform for Rich Client Applications (RCP). The central architectural element of these applications is precisely the Workbench (also called the Generic Workbench to differentiate it from the IDE).
Programmatically, the Workbench is represented by interface
which can be obtained as a singleton instance by calling
The Workbench provides a variety of services, most of which we won't
address here. It also provides access to its visual components, starting
with its windows; while there may be more than one window (represented
IWorkbenchWindow) in a Workbench application,
at most one can be active at any given time. Each window consists of
multiple pages (
IWorkbenchPage; although having more than
one page is rare), of which only one may be active at any given time.
At this point you may be tempted to think that switching perspectives is equivalent to flipping the window's pages. This, however, is not the case. Programmatically, a perspective just defines the page layout (which is, by the way, fully customizable by the user). When you switch perspectives, you actually apply a different layout (and a corresponding set of views) to the same page.
Finally, each workbench page consists of several "parts" — editors or views (and again, only one may be active at a time).
Each of these interfaces provides access to components and services
pertinent to their level within the hierarchy. For instance,
allows you to show views, open editors, and manipulate the current
IWorkenchWindow lets you work with its
IWorbench with windows and other Workbench-wide
This hierarchy stops at
IWorkbenchPart, because this is
where customization comes to play: each view or editor implements its
own user interface and provides its own services.
Several views are considered "standard" — Properties and Content Outline in the Generic Workbench, Problems, Tasks, Bookmarks, Resource Navigator, and some others, in the IDE. Many of these expose public APIs that you can peruse in your own solutions.
While editors and views perform different functions within the
Workbench, they have much in common — they are "parts" of the
Workbench, and as such they must follow a certain protocol common to all
Workbench parts. This protocol is embodied in interface
which all Workbench parts must implement.
While developing your own views or editors, you will notice that instead of directly implementing the corresponding interface, you are asked to extend an abstract base class (
ViewPartfor views and
EditorPartfor editors, respectively). This approach is actually quite common throughout Eclipse. It gives the API providers the flexibility to amend and evolve the API (i.e., the interface) without inadvertently breaking backward compatibility. For example, if they decide to add a new method to the interface, then all existing implementations would break, unless updated. If, however, the implementations extend an abstract class, then that class can provide the default implementation of this method, without breaking any existing subclasses.
In the previous article's example, the SuperView's
method was implemented in order to construct its user interface components. The
method's argument were used as the parent Composite for the viewer. In fact,
Workbench parts are essentially user interface widgets displayed and
managed by the Workbench in a specific way. Thus, this method is called
by the Workbench at the appropriate time within the part's lifecycle in
order to create its visual representation. If the part allocates any
platform resources during construction, it must dispose them in its
Workbench parts are often dynamic in nature and may need to
communicate any relevant state changes to the Workbench. For this
reason, each Workbench part supports a property change notification
protocol — interested parties may add themselves as
which the part then notifies when one of its properties changes. Just
what these properties may be depends on the part type; one common
property shared by both views and editors is their title.
The Workbench supplies each of its parts with instance-specific
services by means of a "site" (
IWorkbenchPartSite) — the
primary interface between the part and the Workbench. The way in which
views and editors are supplied with it differs, but what they do have in
common is that both are initialized with a site provided by the
Workbench before their user interfaces may be constructed (views
actually get a view-specific subtype of the site, as do the editors).