E4/DeclarativeUI/Styling Roundup
Contents
Notes from the CSS Roundup call August 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
- Matthew Hatem's presentation
- 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
- Angelo Zerr's presentation
- EPL
- Supports the usual selectors
- 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
- Yves Yang's presentation
- 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
RAP
- Ralf Sternberg's presentation
- RAP has pre-existing CSS support for theming
- RAP theming defines the default look of widgets, it does not use API to set properties
- Already EPL at Eclipse
- Main goal is that whatever is adopted, RAP and e4 desktop should be same approach
- Support all the usual selector types
- Reuse CSS property names where possible
Call Prep - Comparison of Styling Technologies
List of Technologies
(Please fill in the template below and a link here to the resulting page)
| Technologies |
|---|
| eFace - XAML for Java |
| TK-UI CSS engine |
| RAP theming CSS flavor |
| Other technologies... |
Prep Template
We'd like to have a call to compare the different CSS technologies folks have proposed. In order to facilitate this, here is a template. Please create a new page with the information filled in.
Notes from Summit breakout session
CSS/Styling
- Too hard to put a custom UI on the workbench
- Each area has its own way to customize
- One single, pervasive easy way to customize the workbench
Use cases
- Closed: take a set of plugins that you know about, package up together, and determine the look
- Extendable: drop a plugin in and it should 'right', like it belongs.
- SWT element should be CSS aware
--Yves Yang 04:58, 28 May 2008 (EDT)
Possible solutions
- manual way: an utility class to apply the style on each SWT widget through the hierarchy tree (Angelo's Tk-UI).
- automatic way: the style values are used automatically when the local property is not set.
| Pros | Cons | |
|---|---|---|
| Manual way | Can be used directly on any SWT widgets | Not local property setting, Can be used for simply mechanism (difficult to trigger the style with data binding) |
| Automatic way | Flexible and powerful | Need a default value search concept for each property |
--Yves Yang 04:58, 28 May 2008 (EDT)
Declarative UI
- Very poor reusability
- Too much code required to get what you want
Goals:
- Change UI without rebuilding the world
- Facility the creation of GUI Builders
- Separate the composition from the styling
- More concise leads to easier to author
- Almost language neutral
- Separate appearance from business logic
Questions:
- Layout engines: we have many, CSS is another. Do we expect to get the CSS layout or just use it for borders, colors, fonts, etc. and not layout.
- Does CSS allow the writing of sufficiently reactive layouts such as our workbench or Notes?
--Yves Yang 05:15, 28 May 2008 (EDT)
Markup Languages
- JSF
- XAML
- XUL
- XSWT
(This is a quick comparison)
| Pros | Cons | |
|---|---|---|
| JSF | Abstraction of GUI, Maturity and popularity, Java standard | Web oriented |
| XAML | Abstraction of GUI, High extensible, maturity and popularity, existing tools and compatibility with Silverlight | New GUI concepts and language to learn |
| XUL | Maturity | New GUI concepts and language to learn |
| XSWT | SWT specific, easy to use for SWT developpers | Maturity and popularity ? |
--Yves Yang 05:15, 28 May 2008 (EDT)
UI Modeling
Adding to the above mentioned languages one can make use of a Platform independent UI Modeling language that specifies the intent of the UI, but not the technical implementation. By cleanly separating the intentions from the technical implementation you can have a single set of specifications generated into several target platforms. StUIML does this and I hope te be able to contribute the metamodel this summer to the PMF (Presentation Modeling Framework) project as soon as I get the green light at my current project. The current tooling around StUIML makes extensive use of EMF and related technology.
--Jim van Dam 11:36, 28 May 2008 (GMT)
Thanks Jim for adding this tropic. In fact, I wonder if your intent of the UI is same as what I said "Abstraction of GUI". In my opinion, a declarative UI needs first a Platform Independent UI MARKUP (instead of modeling) language (PIUIML), which is implemented obviously in EMF. The UI Markup language must be abstract. I prefer referring the modeling language to high level concept.
Useless to say that the PIUIML model is very important for development tools. It can be used directly by Visual editor or/and indirectly by domain modelers via PMF.
--Yves YANG 09:42, 28 May 2008 (EDT)