Description Brian de Alwis 2014-04-01 14:59:30 EDT

I have a prototype of a CSS Engine that I'll be committing to the e4.ui repository shortly.  This engine is analogous to the CSS-SWT engine but it works directly against the E4 Workbench model elements, rather than indirecting through the SWT widget's modelElement/OWNING_ME.  This allows bug 362420 to be addressed with CSS by the toggling the visible flag directly:

   ToolControl#SearchField { visibility: false; }


Issues that arose:

1. CSSEngineImpl's element provider support only walk the object class hierarchy and ignore the interfaces, which doesn't work for EMF-based objects.  I cleaned up CSSEngineImpl by extracting out the registry-based element provider to a separate class, and also added support for walking interfaces.

1.5. The relationship between AbstractCSSEngine's elementProvider and widgetMap was never very clear (viz bug 363053).  And from looking at AbstractCSSEngine#handleWidgetDisposed() the widgetMap looks like it was supposed to be literally a map of widgets to elements, rather than widget classes to element providers.  Since the only other use was for a test case, which was easily rewritten to use an IElementProvider, I've tossed the widgetMap.

2. ThemeEngine missing #getCSSEngines() so as to provide access to the CSS engines being managed; we want a single set of CSS files that can be interpreted as required.  This is only necessary for the CSS Scratchpad