Re: [eclipse-incubator-e4-dev] CSS DOM Binding

[Kevin McGuire <Kevin_McGuire@xxxxxxxxxx>]

> a) Have an SWT.Create event that would be called
for widget creation

Yeah I like this one too and assume Steve Northover would
prefer it so as not to sully his widgets with CSS info. But I also understand
the desire to have explicit API rather than squirrling things away in untyped
userData slots.  This feels like it'd be nicely represented in aspect
oriented programming.

> This allows the Styling/CSS framework to intercept
these events (via
> a Display.addFilter(...) and do styling before they are presented
tothe user).

To be precise though, the styles must be applied at the
very end of the create, before control is returned to the client code which
instantiated the widget.  I am assuming thus that if I create a widget,
which has a matching style that sets its foreground color, and then immediately
after create I do widget.setForeground(myColor) then myColor wins.

> b) There needs to be some notion of id / class to widgets so you can
> target CSS styling if you want to
> 
> This can be done via the Styling/CSS framework on widget creation
or
> handled internally by SWT somehow. All this stuff could be stored
> via setData(...)

Eric and I were discussing this this morning.  The
interesting part for me is where do the CSS classes come from?  I
think they come from the UI model we've previously discussed.  I find
them by reading off the nodes in the UI model.  This allows us say
to differentiate editor stack from view stack (both of which are CTabFolders),
or the perspective switcher from the fast view bar element (both of which
use the same underlying widget).   The UI model is where we're already
encoding the existance of a FVB, a PerspectiveSwitcher, etc.  The
CSS classes are semantic tags against widgets (or HTML elements), where
the widgets are reused under different contexts, with the CSS classes denoting
these different contexts. Those contexts are encoded in and read off from
the model.

In functional terms, this means that the model's widget
factory sets CSS classname and ID into the widget, which the CSS engine
picks up to apply the right style.  That's the contract between the
model and the styling engine. It also nicely matches the best practice
way which the model (or any other client code) interacts with styling elements
of the widgets (vs. say directly setting a widget's background color as
we do currently in the model).

> c) PDE/Platform UI provide some type of pimp CSS
editor that is some
> how "SWT aware" to make all this easy
> 
> That's at least how I picture things in my mind currently.

Yes I think this is a must have. 

But related is the UI model and whether it also would
require tooling.  That I'm not at all clear on since I don't yet fully
understand the relationship between the two, or what the UI model is used
for, when, to what aim.

> Once 3.4 is finally closed, I'm sure people will
be excited to prototype this. 

Oh yes, I'm itching to.  We've
had a few people step forward now with technology in this area.  One
thing I'd like to see (so I guess I better organize it) is a conf call
where we go through them all to understand what each is bringing to the
table.  I just haven't been able to keep up with all the email and
look at each in depth, and am betting others are in the same boat.  So
a level set would be helpful.

> I even hear
a certain handsome gentlemen by the name of Matthew Hatem has some code
kicking around.

Personally, I really like his hair.
 He had that kind of "tussled but serious" look at the e4
summit that I thought was oh so apropo for the event.

"Christopher Aniszczyk" <caniszczyk@xxxxxxxxx>
Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx

06/09/2008 11:29 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] CSS DOM Binding

2) General purpose API added to SWT
that will enable CSS 

I like this approach as it keeps SWT as lean as possible. The additions
to SWT would work like this in my mind:

a) Have an SWT.Create event that would be called for widget creation

This allows the Styling/CSS framework to intercept these events (via a
Display.addFilter(...) and do styling before they are presented to the
user).

b) There needs to be some notion of id / class to widgets so you can target
CSS styling if you want to

This can be done via the Styling/CSS framework on widget creation or handled
internally by SWT somehow. All this stuff could be stored via setData(...)

c) PDE/Platform UI provide some type of pimp CSS editor that is some how
"SWT aware" to make all this easy

That's at least how I picture things in my mind currently.

Once 3.4 is finally closed, I'm sure people will be excited to prototype
this. I even hear a certain handsome gentlemen by the name of Matthew Hatem
has some code kicking around.

Cheers,

~ Chris Aniszczyk _______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev