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 <tom.schi...@bestsolution.at>:
> 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 <dschae...@qnx.com>:
>
> JavaFX has it's own CSS. It'll be interesting to see how the two will play
> together.
>
> Doug.
>
> ------------------------------
> *From:* e4-dev-boun...@eclipse.org [e4-dev-boun...@eclipse.org] on behalf
> of Brian de Alwis [briandeal...@gmail.com]
> *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 <emoff...@ca.ibm.com> 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 <briandeal...@gmail.com> <ecblank.gif>
>
> To:
>
> <ecblank.gif>
> E4 Project developer mailing list <e4-dev@eclipse.org>, <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>
> e4-dev-boun...@eclipse.org
>
> ------------------------------
>
>
>
> 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*<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/*<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
> e4-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
>
> _______________________________________________
> e4-dev mailing list
> e4-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
>
> _______________________________________________
> e4-dev mailing list
> e4-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
>
> _______________________________________________
> e4-dev mailing list
> e4-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
>
_______________________________________________
e4-dev mailing list
e4-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/e4-dev
