E4/UI/Toolkit Model

The Toolkit Model

The Toolkit Model is an EMF model of the user interface (UI) components (aka. widgets) found in toolkits like Swing and SWT. The model includes concepts like Composite, TabFolder, Text, Layout etc. that define the structure and content of a user interface. An instance of the Toolkit Model (henceforth shortened to TM) represents all or part of a specific UI, like an application window or form, but is not itself a runnable/running UI. Instead, a concrete UI in a specific toolkit is built and bound to the TM instance, to create a running user interface. By bound, we mean that the two representations, the TM instance and the concrete UI (widgets), are kept in sync, so changes to one are propagated into the other. There may be limitations to this synchronization, so the typical setup is:

• The application manipulates the TM instance to change the concrete UI, e.g. set the "text" EAttribute of a Text EObject instead of calling the setText method of the underlying Text widget. This should work for arbitrary changes, like moving widgets around in the hierarchy and changing widget behavior, look & feel and layout.
• The application reacts to user interaction by listening to changes to TM instances, e.g. when the user edits the text in a Text widget, the "text" EAttribute of the corresponding Text EObject is updated and a normal EMF Notification is delivered. Usually you will listen to changes to value-oriented attributes, like text value or selection. In addition, events are represented as transient attributes holding toolkit-specific values.
• Each TM widget instance may have references to application data, and by using EMF's Javascript support, changes to these references may trigger UI changes.

There are several advantages to this setup:

• The Toolkit Model is a (slight abstraction) of the underlying toolkit, and may hence be conceptually simpler and easier to work with.
• EMF provides a simple set of concepts and a uniform object structure for the UI, that hides the technical details of the underlying toolkit.
• The reduced coupling that binding gives, makes it easier to support different architectures where the concrete UI runs in a different process on a different machine on the network, e.g. a thin client or web browser.
• An application designed with EMF will be easy to bind to an EMF-based UI. EMF instances representing the application data and UI state can be saved and loaded together and used as session data.
• Although the TM instance may be build by hand using EMF tools, it may also be the result of a model-driven engineering process. E.g. the UI may be generated from a prototyping tool or a domain model with styling templates.

There are also disadvantages, particularly:

• The model introduces a set of intermediary objects, and hence is more bloated than having only the underlying toolkit's widgets.
• You may be unfamiliar with EMF or it may be considered inappropriate for UI programming.

The plugins

There are currently three main plugins in the TM feature

• E4/UI/Toolkit_Model/org.eclipse.e4.tm provides the model itself with support for most simple widgets, but not complex ones like trees and tables
• E4/UI/Toolkit_Model/org.eclipse.e4.tm.builder provides a builder for SWT, so the model may be bound to a concrete SWT UI
• E4/UI/Toolkit_Model/org.eclipse.e4.tm.ui provides an editor (very in-progress) for building applications based on EMF, TM and Javascript and supporting views, including views for previewing TM instances and editing Javascript source.

The Javascript support is provided by the E4/UI/Toolkit_Model/org.eclipse.e4.emf.javascript plugin. In short, it makes EMF objects look like native Javascript objects, so both EMF-based data and UIs (since TM is EMF-based) can be scripted.