Difference between revisions of "E4/DeclarativeUI/Styling"

Revision as of 19:40, 20 August 2008

Styling Eclipse

This page is to collect issues and notes about styling approaches in e4. At at technical level there are two main approaches:

• CSS
• XAML

Notes/Issues from CSS Roundup call Aug 20

General CSS

• Widgets will need an ID and CSS classname associated with them. How best to do this? Widget.setData()?
• HTML selector, of practical value?
  • Pro: One can reuse existing stylesheets directly in Eclipse
  • Con: Its unlikely you can do that in practice since there will be specifics about the Eclipse UI which are not captured in some pre-existing web style sheet
  • Pro: If your product has both a desktop and a web component, you can engineer some sub section of the style sheets so that you can reuse them in both places.
  • Pro: Reuse the learning: if people already know CSS for the web they can more easily author a style sheet for Eclipse
• How best to represent attribute selection, as individual elements or as a list?
  • Concensus seems to be as a list
• Pseudo classes like :focus require a focus listener on the widget
  • Can we optimize this so that we only add listeners on widgets which would selected? (ie. those which the style would select to, and thus would require the listener to trigger the style change?)
• Lazy v.s. explicit strategies for applying styles to widgets instantiated at runtime
  • Styling must be last thing to happen before control returns from widget creation
  • TK-UI has one strategy based on resize listener but it has technical issues
  • Steve has investigate SWT supporting but problem is that in Java you can't ensure some code is run at the end of initializer if you have subclasses; they will always call super() then do more work.
  • SWT can provide support for all its widgets but any custom SWT widgets will need to do explicitly opt in (i.e. modify their widget creation code) to participate in styling
• Ideally we'd have meta information on the set of CSS properties available for a given widget type so that we can do a good job on a code assist style editor
• CSS3 provides namespaces. We need someway of avoiding name clashing but is this the best way?
• SWT push v.s. radio button - how best to represent
• Best way to represent CSS class in the widget so its clear its meaning (avoid confusion over meaning of "class" in Java)
• Does selection based on ID provide value?
  • Probably not much practical usage in the Eclipse context
  • But should support anyway since not much additional cost
  • However, something to keep in mind as we consider best practice approaches
• Resource management
  • We need resource management in whatever CSS solution we pick
  • Ideally we should make use of the JFace resource management if JFace present

Matt's Lotus Experience

• Need for supporting extensions (e.g. to do gradients), right way is ["-moz-xxx"]
• Lotus requirements
  • Ability to extend
  • Object model
  • Concern over speed/space (issues at present)
  • They call CSS code after widget creation so clearly nicer if SWT can provide support
  • Mapping between CSS colors and SWT colors

TK-UI

• EPL
• Picked Flute because wanted to support CSS3 for namespaces and Flute grammar easier to change than Batik
  • But Flute may have no one maintaining it and may be slower or bigger
  • Alternative approach is either live without the grammar changes, or work with Batik community to add required support there
• Stores ID and CSS Class in Widget.setData()
• Has an indirection strategy for how we lookup ID and CSS Class on a widget. Do we need this indirection?
• Resource management
  • TK-UI has its own since wants to be independent of SWT/JFace
  • Ideally would call through to JFace one if JFace present.

eFace

• Styling is part of the overall XAML package
• So can't really just talk about styling independently
• Not CSS
• Styling is via XML, where fonts and colors are just properties on the widgets which can be set (like any other property)
• Styling information can be embedded in widget markup or separated
• Events are properties that act as triggers
• Supports named styles
• Has databinding
• eFace source not yet licensed
• But eFace can be downloaded and tried out
• XAML license permits anyone to implement