I think every element should
be styleable. And the access of the styled value should be transparent in
default mode since in most of case we don’t care.
The class Style in the below
example can be replaced by a style provider interface. The default value mechanism
is very important, which can be used for other purpose in subclass such as
template, data binding etc.
yves
From:
eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
[mailto:eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx] On Behalf Of Eric Moffatt
Sent: Monday, April 07, 2008 9:59
PM
To: E4 developer list
Subject: Re:
[eclipse-incubator-e4-dev] Initial discussion onthe'modelled'workbenchUI
Tom, there may (or may not) be a stub there already. At
one point I was working on a subclass of ModelElement called
"StyledElement" that had overrides much like those in the
'refreshCTabFolder' method (i.e. they take 'local' values first but will get
values out of a referenced element as needed.
How
much CSS and what form it takes are TBD but my rough guess is the more the
better...;-)
Onwards.
Eric
|
Tom Schindl
<tom.schindl@xxxxxxxxxxxxxxx>
Sent
by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
04/07/2008 03:52 PM
|
Please
respond to
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
|
|
|
To
|
E4 developer list
<eclipse-incubator-e4-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
|
Re: [eclipse-incubator-e4-dev]
Initial discussion onthe'modelled'workbench
UI
|
|
Kevin
McGuire schrieb:
>
> Hi Tom,
>
> >>How much CSS Browser have do we
want to support? Do we for example want
> >>to allow setting more than one
style-class for an element like Browser
> >>allow it (Pseudo SWT-HTML):
>
> >> <tabItem class="myCTabStyle
selectedMyCTabStyle">
>
> >>In fact I think every attribute
the Style-Class has must be refelected
> >>by the UI-Element we look at or
it has to hold the *clone* of style
> >>object because modifing the
background color of an UI-Widget doesn't
> >>background color of all widgets
using this style!
>
> To start I think we're fine just supporting
single class CSS since it
> covers a huge number of cases, and multiple
class CSS hurts the head.
> I'd be open to multiple though.
>
Support multi-classes would immediately solve e.g.
activation vs
deactivation style when the CTabItem is activated
you simply add the
secondary style and if deactivate you remove the
secondary style but I
agree that a one class is simpler for the start.
> But I don't understand the 2nd part of the
question. Can you clarify?
>
> The properties a style-class describes must
be reflected by the
> UI-Element, although its up to us to decide
how forgiving we are of this
> (for example, typically web browsers just
ignore CSS lines which set
> attributes which aren't supported by the
given HTML element). And the
> relationships are unidirectional, with the
classes just acting as
> selectors for applying attribute changes, but
the attributes not being
> "owned" in any way by the CSS
classes.
>
Well this way you restore many duplicate
informations on your
UI-Elements because ~90% they are set and never
changed so copying them
on UI-Element-Creation is not a good solution in
terms of memory usage.
A better approach IMHO would be to wrap on write
something like this:
---------8<---------
public class UIElement {
private Style style;
private class WrappedStyle extends
Style {
private HashMap ownMap
= new HashMap();
private WrappedStyle(Style
style) {
this.style = style;
}
public String
get(String name) {
if(
ownMap.contains(name) ) {
return ownMap.get(name);
}
}
public void set(String
name, String value) {
ownMap.put(name,value);
}
}
// Allows reading without the need to
wrap
public String
getStyleAttribute(String name) {
return style.get(name)
}
public String
setStyleAttribute(String name, String value) {
getStyle().set(name,value);
}
public Style getStyle() {
if( !( style instanceof
WrappedStyle ) ) {
this.style = new WrappedStyle(this.style);
}
return style;
}
}
---------8<---------
This of course simplified and only doable if you
have slightly
intelligent Model-Elements.
Tom
--
B e s t S o l u t i o n . a t
EDV Systemhaus
GmbH
------------------------------------------------------------------------
tom schindl
leiter
softwareentwicklung/CSO
------------------------------------------------------------------------
eduard-bodem-gasse 8/3 A-6020
innsbruck phone ++43 512 935834
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
