The UI Model is used to describe the various components of an application's User Interface. This model is an abstract definition that is rendered into reality on a particular platform through the use of a presentation engine driving a set of renderers (usually but not limited to one renderer part UI Model type.
The model itself is based on EMF. One of the things that EMF does a really good job at is allowing multiple inheritance so the basic design of the model starts with low-level components that can then be aggregated into concrete classes.
The model itself is composed from a number of different type of elements which are used to define the 'concrete' UI elements (i.e. the ones that actually get rendered):
Used to contain the attributes for different concepts such as label information or containment types. These will be useful when we eventually start to derive domain-specific models based on the current one.
In order to facilitate the use of Java generics each container may only contain elements of a single 'type' (interface really). These elements represent the type that is legal in a given container. In order to make an element legal for a given container add that container's type as one of the mix-ins for the class being contained.
WindowElement - Elements that can be added to a Window's list of children:
TrimElement - Elements that can be added to a TrimBar
PartSashContainerElement - Elements that can be added to a PartSashContainer
- PartSashContainer (it's recursive)
StackElement - Elements that can be added to a PartStack
These define the true UI model as used to present an applicaton. The UI Model has been broken down into a number of discreet packages, the sections below will be based on the contents of each package:
This package contains the most elementary of the UI components:
MTrimBar (contained by an MTrimmedWindow but not in its list of children)
Basic UI (Descriptors)
This Package contains the 'descriptors' for various elements. Currently only PartDescriptors are supported but over time we may well want to include other types such as PerspectiveDescriptors. Essentially this is the e4 way to capture the set of available views that a user may wish to open and from which the actual MPart can be instantiated.
This package contains the elements necessary to support more complex UI's such as are required by the Eclipse IDE itself such as Perspectives and (editor) Areas.
This package contains the elements necessary to support the Commands infrastructure. Here a single command is referenced by any number of Handlers (at most one of which will be active in any given UI context.
MBindingTable Not sure we want this as API for now since we may want to combine or modify how these are used
MParameter Do we need this ?
Menus (and Toolbars)
This package contains the elements used to define menus, toolbars and their corresponding items. There are two flavors for the items, 'direct' and 'handled' based on wether the item is backed by a Command or not.
MMenuContribution This appears as if it should be part of the snippet story
MOpaqueMenu This is unnecessary (we can use different renderes for a standard MMenu now)
MOpaqueMenuItem This is unecessary
MOpaqueMenuSeparator This is unnecessary
MOpaqueToolItem This is unnecessary
MPopupMenu Do we nned this...why does a popup menu need a context ?
MRenderedMenu This is unnecessary
MRenderedMenuItem This is unnecessary
MRenderedToolbar This is unnecessary
MToolBarContribution This appears as if it should be part of the snippet story
MTrimContribution This appears as if it should be part of the snippet story