Bugzilla – Full Text Bug Listing
| Summary: | [CSS] getAllCSSPropertyNames() should be scoped to CSSStylableElement | ||
|---|---|---|---|
| Product: | [Eclipse Project] e4 | Reporter: | Aghiles Abdesselam <aghilesa> |
| Component: | UI | Assignee: | Project Inbox <e4.ui-inbox> |
| Status: | RESOLVED WORKSFORME | QA Contact: | Bogdan Gheorghe <gheorghe> |
| Severity: | normal | ||
| Priority: | P3 | CC: | azerr, Kevin_McGuire |
| Version: | 0.9 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | stalebug | ||
Angelo, comments? I agree with the 2 problems. The compute style for default style must be re-thought. The default style is used :
* to set default style to a widget when focus is lost and the widget had style applyed (ex : Text:focus{color:red;}, when the focus is lost color must be blank (default style))
* reset style which was applyed when CSS stylesheet change.
Morever default style is relied on state of widget. For instance if widget is enable, default color is blank although if widget is disable, default color is gray. Today we can manage that.
So I think default style must not computed, and must be managed with SWTElement (CSSTylableElement as Aghiles Abdesselam have suggested).
Angelo
(In reply to comment #2) > I agree with the 2 problems. The compute style for default style must be > re-thought. The default style is used : > > * to set default style to a widget when focus is lost and the widget had style > applyed (ex : Text:focus{color:red;}, when the focus is lost color must be > blank (default style)) > > * reset style which was applyed when CSS stylesheet change. > > Morever default style is relied on state of widget. For instance if widget is > enable, default color is blank although if widget is disable, default color is > gray. Today we can manage that. Did you mean to write *can't* manage that? I remember you discussing this issue before. Right, the problem is that we can't determine what the widget's default state is, only what state it was in when we first saw it. So if the first time you see the shell it's active, then you don't know what to set the values back to when it's not. Generally SWT allows you to reset properties to their default state by using null as the argument (e.g. see Control.setForeground()). That's ok provided nobody has programmatically changed the foreground, so the best we can do reliably is reset to system default, potentially "fighting" with an application. Might this be acceptable in practice? (or at least, unnavoidable?) We can never know when application code got in there to modify a widget's look (e.g. it might do it after we styled it, believing that should now be the default). > So I think default style must not computed, and must be managed with SWTElement > (CSSTylableElement as Aghiles Abdesselam have suggested). Actually it was me using his computer but I'm sure he agrees :) The suggestion was just that we shouldn't be calling getCSSPropertyStyle() for properties which aren't valid for that element type (or, it should know to return null without ever attempting to apply that property handler to that unmatched element type). I assume we could address this as part of the larger discussion over having the properties associated with an SWTElement subclass. But that doesn't answer the question of whether we *should* be trying to capture the property state. Maybe resetting to default should be to just use null for the value in the SWT call. More sophisticated solutions would involve some kind of SWT support, such as ability to determine if the current widget state differs from the default or notification of programmatic change. Hi Kevin,
>Did you mean to write *can't* manage that?
Right! Sorry for my mistake.
To reset style we can use null value. It works for SWT, but I think we should think about another CSS engine implementation (Draw2d, style EMF instance...) and I think it's importtant to have reset behaviour. Today my idea are very confused, so it's difficult to give you sample.
IMHO, Kevin I think we should think about stateless CSSStylablement(singleton SWTElement as we have discussed together) before develop that.
Angelo
(In reply to comment #4) > To reset style we can use null value. It works for SWT, but I think we should > think about another CSS engine implementation (Draw2d, style EMF instance...) > and I think it's importtant to have reset behaviour. Good point. It argues that resetting should be up to the element type. If it's an SWT element it uses null. If it's something else then maybe it needs to capture and remember state. That behaviour could be reusable (e.g. there's some utility code available) but not the default behaviour, each element type must decide. > IMHO, Kevin I think we should think about stateless CSSStylablement(singleton > SWTElement as we have discussed together) before develop that. Agree! This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. This is a mass change to close all e4 bugs marked with "stalebug" whiteboard. If this bug is still valid, please reopen and remove the "stalebug" keyword. |
When you applyStyles and compute defaults, an interation in CSSPropertyHandlerSimpleProviderImpl.getDefaultCSSStyleDeclaration() looks like: Collection propertyNames = getAllCSSPropertyNames(); for (Iterator iterator = propertyNames.iterator(); iterator.hasNext();) { String propertyName = (String) iterator.next(); String s = getCSSPropertyStyle(engine, stylableElement, propertyName, pseudoE); But not all properties are applicable to all types of elements. We then attempt to retrieve every property type for the given element, regardless of whether that property was defined for that element type. There are two problems: 1) Poperty retrieval must always guard against being called with an unmatched element type. 2) It's wasteful calling every property handler for unmatched element types.