> 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" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 06/09/2008 11:29 PM Please respond to E4 developer list <[email protected]> To "E4 developer list" <[email protected]> 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 [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
