Skip to main content
Jump to: navigation, search

Ralf Sternberg

Ralf Sternberg is a committer to the Rich Ajax Platform (RAP), working for Innoopract in Karlsruhe, Germany. His main work area is RWT, the RAP SWT implementation, especially topics related to UI styling and theming. This is only a wrap-up


I'm especially interested in the declarative UI and CSS styling features of e4. In RAP, we implemented a CSS theming subsystem and we would love to see a convergence between the RWT theming and the CSS support in e4.

I also mentored the implementation of a [[RAP_Theme_Editor|theme editor for RAP] as a GSoC project. This editor might also provide a good basis for CSS tooling in the platform.

CSS call preparation

In a discussion with Frank we came across a couple of architectural details that are still unclear to us. I'd like to suggest that we try to clarify those higher-level questions before we move on to actually choosing a technology.

The following is only a wrap-up that might serve as a skeleton:

Feature list

  • To which extent should SWT widgets be stylable by CSS?

E.g. colors, borders, tab sizes in CTabFolder, curved images in CBanner, ... Only API or also internal properties?

  • Should it be possible to switch themes at runtime?
  • Which selector types should be supported?

Child selectors, descendant selectors, ..., see also E4/DeclarativeUI/RAPThemingCSS

  • Should we use namespaces?
    • namespaces == package names? -> SWT custom widgets had to be prefixed
    • alternatives:
      • different namespaces that allow to group all SWT widgets
      • declarative approach as in RAP

Architectural decisions

  • Will CSS styling be an SWT feature or only available on a higher level? In other words, can style sheets be applied to plain SWT apps or are extension points etc. needed?
  • How to style Workbench elements? Will CSS styling be applied to the real SWT widgets or to higher level elements?

We see conflicting requirements here: On one hand, the designer (or whoever writes the style sheets) should not need to know about the exact widget structure. Moreover, the concrete implementation depends on the presentation being used, maybe also to the size of a view part, etc. On the other hand, fine-grained styling is not possible without knowing the widgets and a higher-level styling doesn't seem to make much sense.

  • Get an idea of the development process: Which roles are involved? Who eventually writes the style sheets?
  • At which point will the style sheets be passed to Eclipse?
  • How are CSS style sheets related to presentations?

E.g. different style sheets per presentation, will a presentation switch exchange style sheets?

Implementation aspects

  • How to apply properties to widgets?
  • Which parser/technology to choose?
    • Batik
      pro: Apache License, already in Orbit
      contra: SVG-coupling, no Locator to get text ranges
    • Flute
      contra: not maintained anymore?
    • SteadyState
      pro: seems to be the most advanced CSS parser around
      contra: LGPL

Back to the top