[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse-incubator-e4-dev] Initial discussion onthe'modelled'workbench UI
|
There's some relationship (which isn't clear to me yet) between CSS classes
+ how we might use them, and this strong typing notion...
If I'm building a web page, and I mark something as "class=sidebar", it's
because I want to apply a particular style element, say font, so that all
things that are in the 'sidebar' match. I don't actually care, whether it's
a <p> or a <li>. To my mind, this seems like it is similar to saying that I
don't care what the class of the model object is, as long as it has the
font attribute. (And even if it doesn't, that's ok as long as it isn't
displaying text (that should match)).
Am I off track here?
McQ.
Eric
Moffatt/Ottawa/IB
M@IBMCA To
Sent by: E4 developer list
eclipse-incubator <eclipse-incubator-e4-dev@eclipse.o
-e4-dev-bounces@e rg>
clipse.org cc
Subject
04/07/08 03:59 PM Re: [eclipse-incubator-e4-dev]
Initial discussion
onthe'modelled'workbench UI
Please respond to
E4 developer list
<eclipse-incubato
r-e4-dev@eclipse.
org>
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@bestsolution.
at> To
Sent by: E4 developer list
eclipse-incubator-e4-dev-b <eclipse-incubator-e4-dev@xxxxxxxxxxx>
ounces@xxxxxxxxxxx cc
Subject
04/07/2008 03:52 PM Re: [eclipse-incubator-e4-dev]
Initial discussion
onthe'modelled'workbench UI
Please respond to
E4 developer list
<eclipse-incubator-e4-dev
@eclipse.org>
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
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
