Community
Participate
Working Groups
The CSS support needs to associate CSS class, CSS ID and style sheet with a given widget. It currently does so by using Widget.setData(). This has the advantage that callers do not need to create a dependency on CSS packages, but has the problem that setData() lacks notification of value change: if any of CSS class/id/stylesheet of a widget change, style information must be reapplied. We either need custom API for setting these values (e.g. Widget.setCSSID(String), Widget.setCSSClass(String),...), or we need notification of Widget.setData() change. An issue with the latter approach is blanket broadcast notification of everyone who happens to store values on a widget and wants notification (i.e. the values tend to be orthogonal extensions of the widget data so listeners will only be interested in a specific subset of the keys). Thus a notification mechanism based on key set would be best.
... or an (ugly) API elsewhere. Is the fact that ids etc. are implementated as widget data exposed anywhere?
(In reply to comment #1) > ... or an (ugly) API elsewhere. It's very useful that the API is on the widgets so that we can avoid a code dependency on CSS. This allows people to treat CSS ID and classname as "hints"; if there's a CSS engine there to use them great, if not then oh well somehow the UI will get styled (e.g. 3.x preferences, platform defaults, whatever). > Is the fact that ids etc. are implementated as > widget data exposed anywhere? Semantically yes in that in the client widget creation code you need something like: myWidget.setData("org.eclipse.e4.css.id", "anIdString"); so you need to know both to do setData and what key to use. Technically no in that the value lookups are within the CSS engine implementation.
Are we likely to have platforms where a CSS engine is not around? I'm wondering about platforms where CSS is native and what all this means.
(In reply to comment #3) > Are we likely to have platforms where a CSS engine is not around? Not sure about "platform". We're likely to have product configurations where CSS isn't around but want to use the same widget creation code. > I'm > wondering about platforms where CSS is native and what all this means. For pure web platforms then CSS ID, class name, etc. are properties in the DOM. We've not discussed how a SWTBE widget's properties gets mapped in this regard, so I'm not sure what it means either. However, I think it kind of argues for an explicit API since then SWT could in theory map a call to setting a CSS id on a widget to the DOM value of the underlying web control.
Aside: the CSS requirement here isn't that we need to add a listener at the level of every widget. Rather, we only need a single listener which would provide the widget instance whose CSS id/class/stylesheet changed. I mention this since a generalized approach of having listeners on widget data changes might take the approach of having a listener list on each widget, which would be overkill for our needs.
I believe that one is fixed in Eclipse 4.2, we have custom API to set the ID and class.
