SOFA 2.0 Editor - GUI Repository Designer for Eclipse



SOFA 2.0 repository editor v. 1.3.0 released. Changes »


SOFA 2.0 repository editor v. 1.0.149 released.


Work on the plug-in is started. History »


Compiling and installation

User's manual

Usage scenarios

Developer's manual

UML diagrams

Java docs

Author MaViNes (c)


OSGI Framework

Eclipse plugin basics

RCP basics

SWT draw basics

jFace tips

SWT Linux/Windows differences

Author MaViNes (c)

<< Previous | Table of contents | Next >>

Short workbench overview

The Eclipse platform is structured around the concept of plug-ins. Each subsystem in the platform is itself structured as a set of plug-ins that implements some key functions. Most of changes are visible in the Eclipse Workbench.

The Workbench contains one or more WorkbenchWindows, each of which contains zero or more WorkbenchPages. The WorkbenchWindow supplies the trim widgets, and the WorkbenchPage supplies the window contents. In theory, a WorkbenchWindow can contain any number of pages, but in practice there is never more than 1 page in a window.

Views and editors are owned by the page, through a ViewFactory and EditorManager respectively. EditorManager stores the list of editors and their shared resources, and ViewFactory stores a reference counted list of views. The workbench works in terms of EditorReferences and ViewReferences, and in this article the terms "editor" or "view" will refer to these classes specifically. In situations where the distinction between editors and views is not important, we will simply use the term "part". The implementation of the part (typically an IEditorPart or IViewPart) is created lazily when it is first needed. A part reference exists for every tab but the implementation is only created the first time it becomes visible.

The page owns a set of perspectives. Perspectives contain a layout and information about what action sets to enable. Although perspectives appear to contain views and the editor area, they only own a layout. The page itself maintains a reference count for how many perspectives are using each view, and has complete ownership of the parts and editor area.

Not shown in figure 1 are the classes PerspectiveHelper and EditorAreaHelper. These classes exist largely for historic purposes, and in this article we will treat the former as though it were part of the Perspective class and the latter as part of the WorkbenchPage class.

Ownership of views and editors
Figure 1: Ownership of views and editors

User interface integration

The developed plug-in contributes mainly to the UI of the Eclipse IDE. It closely interacts with Eclipse perspectives, views, editors, wizards, and actions. The UI integration allows the plug-in to participate with the rest of Eclipse UI as if it is designed as a single application.

UI integration is accomplished by building the user interface for the tool using the Eclipse UI frameworks, and integrating with the Workbench through its extension points. Most application development tools (in fact, most tools in general) operate on hierarchically structured data. The Eclipse platform exploits this commonality by providing a number of reusable viewers that can be easily customized through content providers to provide a user interface for a tool's object model. There are many other facilities in the Eclipse platform that support tool UI development including SWT, the Source Editing Framework, contribution frameworks, wizard frameworks, etc. The Workbench provides extension points for adding new views, editors, wizards, preference pages, builders, project natures, perspectives, splash screens, etc. Tools can also extend other tool's menus as well as add extensions to their extension points.

<< Previous | Table of contents | Next >>

Learn More