[e4-dev] First Light for the new UI Model

[Eric Moffatt <emoffatt@xxxxxxxxxx>]

The new UI Model and necessary code
changes have now been committed to HEAD (see the check in notice below
for more details).

I'll be glad to help folks 'port' over
to the new model should they have existing XMI models and would greatly
appreciate feedback on what folks think of the new model...

Should the IDE model contain elements
named 'Editor' or is it more desirable to keep to a more generic 'PartWithInput'
style ?
How important is it for the *model*
to define the containment constraints ?

Suggestions for name changes to classes
and/or attributes welcome (i.e. I just realized that UIElement has a 'factory'
instead of a 'renderer')

The driving motivation for changing
the model should be to make it easy to understand and manipulate while
providing the ability to define the UI shapes that we envision needing.

Now I'm going to start work on the next
'layer', switching the event handling over to the new IEventBroker mechanism...
Eric

Committed in >20091014.

Whew !! This is the implementation for
the new E4 UI Model. This is *not* an end but a beginning...the main thrust
of this design are to try to separate the data holding parts of the model
from the conceptual elements.

The new model has a set of abstract
elements (Context, Contribution, UIItem) and containers (ElementContainer,
GenericTile) that represent the possible state infromation. It then defines
two structural models by creating non-abstract leaf elements (Part, PartStack,
Window) that define their state by deriving themselves from one or more
of the abstract elements. The idea here is to write the bulk of our code
(and tests) against the abstract elements, the structural models are there
to allow for the definition of particular containment structures (EditorStack...).

Main differences from the old model:

Generics are no longer abstract; the
structural models provide java level tooling support since all the generic
types are now concrete (i.e. a PartStack can contain Parts but not Menus...).

There is a much clearer separation between
simple ui elements and parts. For example Sash's are no longer Parts, they're
just specialized containers for parts. This significantly cleans up the
Context hierarchy as well as allowing non-part elements (Menus & TB's)
to go through the rendering engine.

The menu/tb item's are now directly
derived from Contribution rather than *requiring* that they have the full
Command/Handler/Item triad. Also items are now also menu item containers
so a sub-menu is just a menu item with children and a ToolItem with children
is a DROP_DOWN item. We'll be revisiting / extending this part of the model
once Paul's done with his Commands rework. For now it's worth taking a
look at how the menu structure looks in the new E4photo demo's XMI file
compared to the old one.

No 'policy' attribute...;-)

Feedback is *needed* in order to get
this polished. Questions such as whether 'Editor' should even be a part
of the IDE model are still open (actually, nothing is really fixed if given
sufficient reason to change it).

The downside is that this commit breaks
a few things (bugs coming); Most importantly the compatibility layer will
be essentially 'down' until we can flesh out the E4 infrastructure enough
to support it.