E4/UI/Toolkit Model/org.eclipse.e4.tm

The org.eclipse.e4.tm plugin

The Toolkit Model is an Ecore 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 UI.

The model is split into a generic and toolkit-specific parts. The goal is that the generic part covers the widgets (or other objects) that are common among most toolkits, while the toolkit specific parts extend existing classes. Over time the generic part will grow, as we learn how to model in a toolkit independent. The generic model is found in tm.ecore, while the toolkit specific ones will typically be the toolkit name with the .ecore extension, e.g. swt.ecore. The latter models will reference classes in the generic one, when extending and using them by means of the standard EMF mechanisms.

Note that it is possible to provide toolkit-specific behavior without having a separate toolkit-specific model. The generic model may be annotated with data that is specific to a particular toolkit and its rendering engine (called builder). E.g. generic classes contain annotations that tells the SWT builder the name of corresponding SWT class and which style bits that must be passed to the constructor.

tm.ecore

The generic part of the toolkit model is found in tm.ecore and is split into three packages, widgets, styles and layouts. The widgets package contains abstract classes, like Control and AbstractComposite, and generic ones, like Label, Text and List. The styles package contains classes that are related to non-functional aspects like look & feel, that at some point in time may be handled by a CSS-like mechanism. The layouts package contains classes for controlling the layout of the widgets inside a container, attached to both the container and the individual widgets. The main classes are described below.

The tm.widgets package

The most important abstract widget classes are presented below. The naming is highly inspired by SWT's, perhaps I should introduce an 'E' prefix (for Ecore) to distinguish?

• Control - the superclass of all widgets, and includes attributes for the name (EString), role (EString) and to data (EJavaObject). The name is meant to hold a name that is meaningful to the developer and unique within the container. The role is meant to indicate what function the widget has within a part of the UI, and its interpretation is application dependent. The data provides access to application data that provides context and/or content for the widget. Control mixes in the Scripted class, and thus supports scripting.
• AbstractComposite - the abstract superclass of all widgets that contain other widgets. It includes a containment reference to Control and is parameterized with the subclass of Control that it may contain.
• Composite - the concrete widget container that most commonly will be used as interior nodes in the widget hierarchy.
• Labeled - a mixin for widgets that have a user visible name or text, like labels, buttons and text fields.
• Label - a labeled control, typically used for static text.
• Text - editable text
• Button - the abstract superclass of buttons, subclassed by PushButton (for actions), ToggleButton and CheckBox.
• List - the abstract superclass of widgets presenting a list, subclassed by ComboBox, SingleSelectionList and MultipleSelectionList.
• Group - generic container with a label.
• TabFolder - special container that may only hold Tab instances.
• Shell - top-level container.

Support for complex widgets

The most obvious omission is support for tree and table widgets and more complex variants of lists. It's not that it's very difficult, but there are many design decisions that we are not yet prepared to make. Typical for these are their use of helper objects, like JFace's content and label providers and Swing's models, cell renderers and editors. One possibility is reducing the flexibility by supporting only certain patterns. Another is relying on scripting, which gives full flexibility, but a more heavy-weight solution. We want to support databinding in some form, and that suggests an EMF-friendly solution, since EMF-based data and UI goes well together.

<style type="text/css"></style>

The tm.layouts package

This package defines the two abstract classes Layout and LayoutData. The former is attached to containers (AbstractComposite) and guides how they are laid out, while the latter is attached to individual widgets and provides additional hints specific for the container's layout.

Since layouts are often very toolkit dependent, there is only one generic one defined, RectangleLayout, which is used when the position (and possibly the size) is explicitly specified. It's intended to be used for screen sketches and mock-ups, like those supported by wireframesketcher (http://wireframesketcher.com/blog/).

The tm.styles package

The classes in this package are experimental and currently not used. The idea is to have enough in there to support a CSS engine.

swt.ecore

The SWT-specific model mostly includes SWT-specific layouts (Layout and LayoutData subclasses) and style-related classes (resources). By using these classes, you gain precise control over layout and look & feel, but lose toolkit-independence. The layout-related classes are meant to be precise representations of the Java counterparts, with the same names, attributes, defaults, etc.

Extending the model

The toolkit model may be extended in the same way that swt.ecore extends tm.ecore: by subclassing existing classes in a corresponding packages. Widget classes will typically extends Control and new layout-related classes will extend Layout and LayoutData.