Our current engine implementation is specifically for SWT.

This new engine operates directly against the modelled elements — these rules 
will work regardless of the underlying widget technology (e.g., JavaFX, Vaadin, 
Qt, whatever).  

Brian.

On 2-Apr-2014, at 1:50 PM, Eric Moffatt <[email protected]> wrote:

> Brian, I'm sure I'm missing something but most of this info is already 
> available to CSS:
> 
> - The 'id' is the element id
> - The element's interfaces are included as classes (i.e. MPart, MUILabel....)
> - Any 'tags' are included as classes (i.e. 'draggable', 'active')
> 
> What does this new engine allow that's not already there ?
> 
> Eric
> 
> 
> 
> <graycol.gif>Brian de Alwis ---04/02/2014 12:29:07 PM---I’ve just committed a 
> new CSS engine that operates directly on the E4 Modelled Workbench to the e4 i
> 
> <ecblank.gif>
> From:
> <ecblank.gif>
> Brian de Alwis <[email protected]>
> <ecblank.gif>
> To:
> <ecblank.gif>
> E4 Project developer mailing list <[email protected]>,
> <ecblank.gif>
> Date:
> <ecblank.gif>
> 04/02/2014 12:29 PM
> <ecblank.gif>
> Subject:
> <ecblank.gif>
> [e4-dev] New Workbench Model CSS engine
> <ecblank.gif>
> Sent by:
> <ecblank.gif>
> [email protected]
> 
> 
> 
> I’ve just committed a new CSS engine that operates directly on the E4 
> Modelled Workbench to the e4 incubator e4.ui repository.  This engine works 
> directly against the EMF model objects (MApplication, MWindow, MPart, etc), 
> as compared to the existing SWT engine which operate against the SWT widget 
> hierarchy.
> 
> Why would this be useful?  For example, if you don’t want the Quick Access 
> and Perspective bars (bug 362420), you can add a CSS snippet like the 
> following:
> 
> ToolControl#SearchField, ToolControl#PerspectiveSwitcher {
> visibility: hidden;
> }
> 
> This snippet causes the MToolControl visible=false, unlike the SWT solution 
> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=362420#c37) which hides the 
> implementing composite but causes its space to still be present.
> 
> All of the modelled elements are exposed using the EMF EClass Name (e.g., 
> Application, TrimmedWindow, Part, ToolControl).    The engine currently only 
> exposes the MElementContainer’s children and the contents of an 
> MTrimmedWindow’s TrimBars.
> 
> I’ve added support for the following properties; I chose “wm-“ as a prefix 
> for properties specific to the workbench model:
> icon: the MUILabel iconURI property (must be a URI: e.g., 
> “url(platform:/plugin/…)”)
> wm-label: the MUILabel label property
> wm-tooltip: the MUILabel tooltip property
> wm-toBeRendered: the MUIElement toBeRendered property
> visibility: the MUIElement visible property (must be “hidden” or “visible”)
> eclipse-renderer: the MUIElement’s renderer property; this should be renamed 
> to “wm-renderer”, and I’m not entirely sure that it is implemented correctly.
> 
> And there’s some support for pseudo elements (Part:active, Part:dirty, 
> Part:closeable) and element tags are exposed as CSS classes.
> 
> This new engine has been committed as two bundles, 
> bundles/org.eclipse.e4.ui.css.workbench and 
> tests/org.eclipse.e4.ui.css.workbench.tests to the e4.ui repository:
> 
> http://git.eclipse.org/c/e4/org.eclipse.e4.ui.git/
> 
> If you want to experiment using the CSS Scratchpad then you’ll need the 
> latest org.eclipse.e4.ui.css.swt.theme (>= 0.9.300) and the latest 
> org.eclipse.e4.tools.css.spy bundle from the e4.ui repository.
> 
> Brian.
> _______________________________________________
> e4-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/e4-dev
> 
> 
> _______________________________________________
> e4-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/e4-dev

_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev

Reply via email to