[e4-dev] CSS relationship to e4 workbench

[Kevin McGuire <Kevin_McGuire@xxxxxxxxxx>]

(Was titled: "[e4-dev] API for
Workbench Model" in response to Kai's question but realized the topic
was larger, especially see #1 below)

> I want
to enhance my contacts demo to dynamically create menu items for all styles
in a given directory. 
> Right now there is no Java API for that. Any
thoughts about that?

No but sounds like a great contribution
for a new committer :)  I'd be happy to help with this.


A note on architecture:

Currently the modelled UI is independent
of CSS, with the plugin org.eclipse.e4.ui.workbench.swt listing the CSS
plugins as optional dependencies.  The class WorkbenchApplication
looks for a product property "applicationCSS" which is a path
pointing to the style sheet.  For the photo app it looks like:

         <property
         
     name="applicationCSS"
         
     value="platform:/plugin/org.eclipse.e4.demo.e4photo/css/e4photo.css">
         </property>

If the property is set (and the URI
resolves) then we call the class WorkbenchStylingSupport
which reads in the CSS style sheet
via reflection (ugh).


A few comments:

1) The use of optional dependencies
is cool, but makes writing more code here tricky since it must be reflective
which is brutal to write (I believe Boris has a "reflectify"
refactor but that only helps the first time and change/debug is still a
challenge).  It also is a potential point of introducing errors if
we forget to add the CSS plugins to the product since the tooling won't
warn you of their absence (being optional).

I think it's ok to have the modelled
UI be CSS free.  I question the practical value of workbench.swt being
CSS neutral.  I think a theming story *must* be a part of the workbench
and at present CSS is it.  At an abstract level, I believe that changing
the shape of the workbench and changing the look go hand in hand.  At
a practical level, without the CSS support, we have no way to talk about
colors and fonts in the workbench, and would therefore need some other
preference based theming support like in 3.x.  We're not doing that.

An argument for optional is that you'd
like to avoid the footprint of CSS and just build a 'vanilla' unstyled
RCP app.  But even the embedded guys are interested in CSS.  So
who's the audience?  I think we should just endeavour to fix the CSS
footprint problem, which we want to do anyway.  Non workbench modelled
apps can still be CSS free.

If we still strongly believe that CSS
should be separate from the workbench then we should add a plugin for it,
giving us a place to write non-reflective code.

Side note: we currently have org.eclipse.e4.ui.services.IStylingEngine
with methods that look suspiciously like CSS API <grin>).  Ideally
these methods would be in SWT, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=260406.
 I don't believe it expresses something general about styling, that
you could apply it to any existing styling engine, so we should just admit
it's CSS.  In which case, the service should be declared and made
available logically joined to how we make available the styling engine
itself (either in the workbench or in an optional CSS plugin).


2) A menu for providing the available
styles -- where would this code live?  This decision will be dependent
on the decision in (1) above and (3) below.


3) We currently only have a single CSS
product property which is insufficient. 

Option A)

The obvious option is to instead have
two properties:

1 : applicationCSSFolderPath : an URL
pointing to the directory containing all the style sheets
2 : applicationCSSDefaultName : the
default style sheet name to use

as well as a preference to hold the
current choice, being potentially different than the default.

But that assumes that the menu for choosing
the CSS theme would consist of file names.  I'm not sure that's what
we want to display to the user, a more descriptive name might be nicer,
and there's NLS issues.

Option B)

Would be separate plugin.xml entries
for each potential CSS style sheet, each entry having it's own NLS key,
and the ability to identify one of them as the default.  The disadvantage
is that you can't just drop a new style sheet file in and have it show
up in the menu.  The advantage is NLS as well as the potential ability
to have other plugins add to the list.

Option C)

Finally, we could instead have an entry
in the Application.ecore / xmi for the available styles, which seems the
more "in" way to do it, but makes the notion of style sheets
explicit in the model (good and bad, back to #1 above).  Presumably
it would facilitate the construction of the menu. We could then provide
reusable code for building this menu of available styles, with each RCP
product deciding to include or not include the menu at the XMI editing
level.

Regards,
Kevin

"Toedter, Kai" <kai.toedter@xxxxxxxxxxx>
Sent by: e4-dev-bounces@xxxxxxxxxxx

04/03/2009 11:03 AM

Please respond to
E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>

To	"E4 Project developer mailing list" <e4-dev@xxxxxxxxxxx>
cc
Subject	[e4-dev] API for Workbench Model

All,

I want to enhance my contacts demo to dynamically create menu items for
all styles in a given directory. Right now there is no Java API for that.
Any thoughts about that?

Best regards,

Kai
---

Kai Tödter

Siemens AG
Corporate Technology
Architecture
CT SE 2
Otto-Hahn-Ring 6
81739 Munich, Germany
Phone: +49 89 636-41064
Fax: +49 89 636-45450
mailto: kai.toedter@xxxxxxxxxxx
Internet: www.siemens.com/corporate-technology

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard
Cromme; Managing Board: Peter Loescher, Chairman, President and Chief Executive
Officer; Heinrich Hiesinger, Joe Kaeser, Rudi Lamprecht, Eduardo Montes,
Juergen Radomski, Erich R. Reinhardt, Hermann Requardt, Uriel J. Sharef,
Peter Y. Solmssen, Klaus Wucherer; Registered offices: Berlin and Munich;
Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684;
WEEE-Reg.-No. DE 23691322


_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev