Re: [eclipse-incubator-e4-dev] Initial discussion onthe'modelled'workben

[Eric Moffatt <emoffatt@xxxxxxxxxx>]

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