[e4-dev] UI Model changes

[Eric Moffatt <emoffatt@xxxxxxxxxx>]

For those that synch from HEAD or folks
that will be picking up tomorrow's I-build there has been a major refactoring
of the UI Model (UIElements.ecore). 

Feedback is welcome, just add your comments
to https://bugs.eclipse.org/bugs/show_bug.cgi?id=296478.

MUIElement::
   the old 'visible' attribute
is now called 'toBeRendered'
   the old 'factory' attribute
is now called 'renderer'
   the 'visible' attribute
will be used indicate whether or not a particular element is actually visible
to the User (matching the 3.x 'PartVisible' event)

MUIItem has been renamed to MUILabel
(to avoid confusion with MItem)
   the 'name' attribute has
been renamed 'label'

The model has been thoroughly cleaned
to remove elements that we won't be using. We've decided not to use the
'IDE' containment structures (EditorStack, ViewStack...) for the compatibility
implementation but will instead use the simpler 'RCP' (Part based) model,
hopefully bringing us closer to being able to re-use legacy parts in basic
RCP apps.

The model has also been re-organized
to group the model elements into 'packages' which provide a particular
piece of functionality: For now the packages are simply marked with place
holders in the model but Tom Schindl has kindly offered to turn them into
'real' EMF packages once we're satisfied that the structure is OK (as well
as cleaning up some of the code generation options).

Data Layer: Abstract elements used to
construct the actual model elements using a 'mix in' pattern.

Basic Elements: These can be used to
build simple applications

Menus and Toolbars: All the elements
related to the modeling of basic menus and toolbars
RCP: A part based definition allowing
for a Sash/Stack arrangement whose leafs are MParts

Advanced Elements: These can be used
when the application developer needs extra capabilities. This allows the
builder of an application to 'buy in' by using elements from the following
packages. The packages are orthogonal, allowing the developer to, for example,
use 'Trim' elements without having to pick up any (to him) unnecessary
baggage.

Commands: The Commands/Handlers infrastructure.
This allows advanced features like Key Bindings, menus extension points...we'll
be using this in the compatibility layer to re-implement the current 3.x
menu handling.

Trim: Provides the ability to add TrimContainers
on any side of the MWindow. This is useful for supporting 'main' ToolBars
as well as Status lines...

Editors: Used to handle editors. This
is different from the basic SaveablePart in that it provides an 'inputURI'
to allow the editor to be based off of a resource (or other external) storage.

Coming soon!!

Shared Parts: allows E4 to implement
the current Perspective behavior of re-using the same control (Tree...)
in different places rather than new instances.

Frames: The E4 equivalent to Detached
Windows; separate Shells associated with the 'main' shell whose visibility
is determined by their location in the Model (i.e. visible when the perspective
that they're defined in is 'on top'.

Onwards,
Eric