[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [e4-dev] New Workbench Model CSS engine
|
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 <erdal.karaca.de@xxxxxxxxx>
|
To:
| E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>,
|
Date:
| 04/03/2014 09:51 PM
|
Subject:
| Re: [e4-dev] New Workbench Model CSS
engine
|
Sent by:
| e4-dev-bounces@xxxxxxxxxxx |
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.schindl@xxxxxxxxxxxxxxx>:
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 <dschaefer@xxxxxxx>:
JavaFX has it's own CSS. It'll be interesting
to see how the two will play together.
Doug.
From: e4-dev-bounces@xxxxxxxxxxx
[e4-dev-bounces@xxxxxxxxxxx]
on behalf of Brian de Alwis [briandealwis@xxxxxxxxx]
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 <emoffatt@xxxxxxxxxx>
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 <briandealwis@xxxxxxxxx>
|
<ecblank.gif>
To:
| <ecblank.gif>
E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>,
|
<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-bounces@xxxxxxxxxxx |
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
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev