Plugging into the workbench

By now, you should be quite familiar with the operation of the workbench and how it uses views to display information. If not, read the quick tour of the workbench below.

The sections following the quick tour will look at the workbench user interface from an API perspective. We will show how a plug-in can contribute to the workbench UI.

Quick tour of the workbench

The workbench is the cockpit for navigating all of the function provided by plug-ins. By using the workbench, we can navigate views and we can view content and properties of data sources.

When you open your workbench it looks something like this.

The workbench is just a frame that can present various visual parts.

Workbench under the covers

The workbench provides an extensive set of classes and interfaces for building complex user interfaces. Fortunately you don't need to understand all of them to do something simple. We'll start by looking at some concepts that are exposed in the workbench user interface and their corresponding structure under the covers.

Workbench

We've been using the term workbench loosely to refer to "that window that opens when you start the platform." Let's drill down a little and look at some of the visual components that make up the workbench.

For the rest of this discussion, when we use the term workbench, we will be referring to the workbench window (IWorkbenchWindow). The workbench window is the top-level window in a workbench. It is the frame that holds the menu bar, tool bar, status line, and pages. In general, you don't need to program to the workbench window. You just want to know that it's there.

Note: You can open multiple workbench windows; however each workbench window is a self-contained world of pages and views, so we'll just focus on a single workbench window.

From the user's point of view, a workbench contains views. There are a few other classes used to implement the workbench window.

Page

Inside the workbench window, you'll find one page (IWorkbenchPage) that in turn contains parts. Pages are an implementation mechanism for grouping parts. You typically don't need to program to the page, but you'll see it in the context of programming and debugging.

Views

Views are where we move beyond implementation details into some common plug-in programming. You will be building your view according to a common lifecycle.

  • You implement a createPartControl method to create the Swing widgets that represent your visual component. You must determine which widgets to use and create any related UI elements needed to display your view.
  • When your view is given focus, the JComponent.requestDefaultFocus will be called on the component that is returned from the createPartControl method so that you can set the focus to the correct widget.

Throughout this lifecycle, events will fire from the containing workbench page to notify interested parties about the opening, activation, deactivation, and closing of views.

Seem simple? It can be. That's the beauty of workbench views. They're just widget holders, and can be as simple or complex as you need them to be.