The concept of the modeled workbench

5.1. The model

The Eclipse e4 workbench is modeled via Eclipse EMF . This model contains the graphical elements of the workbench, e.g. the parts (views, editors, menu bars) and some non-visual parts of the command framework, e.g. handlers, commands and keybindings. This model of the workbench is available at runtime, e.g. the programmer can access the running model and change it during runtime.

Eclipse 3.x has a different concept of the workbench, in Eclipse 3.x the Ui elements are defined via extension points and stored in registries at runtime. These registries does not contain the actual relationship between the UI elements. In Eclipse 4.0 the workbench is explicitly modeled. It is also much more flexible compared to the Eclipse 3.x. For example you do not need to have perspectives and there is not an inherent distinction anymore between editors and views (both are called "Parts").

The e4 model consists roughly out of the following packages:

• application: main elements, like IEclipeContext, Application and the following subpackages

• ui - contains general components, e.g. the Context, menus, toolbars, parts and other UI related model components

• commands - definition of commands, handlers and keybinding

• descriptor - used to store information about the ui components

5.2. e4 WorkbenchModel Editor

In e4 the application is based on a EMF model . This model can be created and changed via the standard EMF tooling . The Eclipse e4 provides a specialized model editor (mainly developed by Tom Schindl ) which makes the easier to change an e4 application model. To open the model editor double-click on "Application.e4xmi" (or right click on it and select "Open-with"-> "e4 Workbenchmodel Editor".

5.3. Contributing to the e4 model

The base e4 application model is placed in an XMI file. This file is a standard XMI / text file. The application is at startup informed which file to use via the parameter "applicationXMI" of the extension point "org.eclipse.core.runtime.products". The XMI file is read at start time of the application and the initial application model is constructed from this file.

Model elements can also be supplied via the extension point "org.eclipse.e4.workbench.model". Model elements can be contributed via xmi (fragments) or via code (processors). These elements are merged into the application model. User changes are also recorded and saved independently.

The model information is read during startup and the contained information is to construct the workbench. The complete constructed model is available during runtime. Changes during runtime, e.g. the user moves a part, are written back to the model. If user changes should not be applied to the model you can specific the "-clearPersistedState" parameter as launch parameter. This would then be similar to the configurer.setSaveAndRestore(false) flag in Eclipse 3.x.

5.4. Merging model elements at startup

The e4 model has three potential parts which will be combined at runtime.

1. The application defines in its "Application.e4xmi" file a base model (for example, main menu, perhaps UI elements like views that are always there, etc). This file changes over time as new versions of the application are being developed and released.

2. Other plug-ins add to that model through our model extension point. Plug-ins can be installed and un-installed. This means that we have a model that results from combining the base model with these contributions. Of course, this means that there is an additional source of change to the model, but it is pretty clear how these contributions get merged into the model.

3. While the application is running, the model objects can be changed. For example, views are closed, or menus/toolbars were customized, new views were opened, etc. These changes need to be persisted across sessions, and ideally even across updating plug-ins or the base application. The model delta are captured based on the difference to the real model, e.g. if you move View A to another place and move it back to the original position no delta is saved

The workbench model needs to the user changes and must be able to react to changes in the Application.e4xmi and the model contributions. The workbench models handles this as follows: On first startup, populate the model as described under 1 and 2. Changes during the session will be recorded as deltas, and we persist these deltas instead of the whole model when we shut down. Then, for subsequent startups, populate the model as described under 1 and 2 and then apply any persisted deltas from 3. If there are deltas that don't make any sense then skip them. The delta are applied to the model based on the ID's of the UI component.

5.5. Where to find the meta-model

The workbench model is defined in the plugin "org.eclipse.e4.ui.model.workbench" in the file "model/UIElements.ecore". The "UIElements.genmodel" defines among other things that interfaces for the workbench model starts with M.