(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" <[email protected]>
Sent by: [email protected]
04/03/2009 11:03 AM
Please respond to
E4 Project developer mailing list <[email protected]>
To
"E4 Project developer mailing list" <[email protected]>
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: [email protected]
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
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev
