Hi,

What about the GUI items that are not represented by model? Are there any 
plans to support it in the new engine? Currently using the selectors for 
the pure SWT classes we are able to style proper SWT widgets (with and 
without the model)

thanks,
Daniel




From:
Erdal Karaca <[email protected]>
To:
E4 Project developer mailing list <[email protected]>, 
Date:
04/03/2014 09:51 PM
Subject:
Re: [e4-dev] New Workbench Model CSS engine
Sent by:
[email protected]



If I get it right, there is still a need for renderer specific CSS 
engines:
It seems that this new CSS engine handles "higher level container 
elements" (modelled elements), whereas it cannot style "low level widget 
elements" (for example, SWT Buttons).

So, they have to work *together*, no?


2014-04-03 21:09 GMT+02:00 Tom Schindl <[email protected]>:
The question who wins is clear in this case - the one who uses the java 
API - at least for javafx!

Generally speaking this css solves many issues we have today where we 
encode Information into the model which are better stored outside like 
icons, window trim, maximizing, ...

Von meinem iPhone gesendet

Am 03.04.2014 um 20:24 schrieb Doug Schaefer <[email protected]>:

JavaFX has it's own CSS. It'll be interesting to see how the two will play 
together. 

Doug.


From: [email protected] [[email protected]] on behalf of 
Brian de Alwis [[email protected]]
Sent: Thursday, April 03, 2014 11:47 AM
To: E4 Project developer mailing list
Subject: Re: [e4-dev] New Workbench Model CSS engine

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

_______________________________________________
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