Hi, I would like just say that w3c provides sac.jar whch contains SAC Parser interface. Batik, Flute...has implemented this SAC Parser interface. I think it will be good (as I have done into my TK-UI CSS Engine) to use SAC interface and not implementation and have SAC parser factory as TK-UI SAC parser factory interface ISACParserFactory<https://tk-ui.svn.sourceforge.net/svnroot/tk-ui/org.akrogen.tkui.css/trunk/org.akrogen.tkui.css.core/src/org/akrogen/tkui/css/core/sac/ISACParserFactory.java> .
So Eclipse CSS engine will able to used any one SAC Parser implementation. Regards Angelo 2008/8/9 向雅 <[EMAIL PROTECTED]> > Thank you for previous hint about my wrong thread. I miss the thank in > my last comment.:) > Thank you. > In my last comment, I said, maybe not only parser. Until now, I still > wanna say: maybe not only the parser. > From work time watching, You still at work time:) I enjoying 2008 > BEIJING:) DuLi, > previous champion, lost the GOLD in the first match, I feel a bit > regret. Our reporter already give her some comfort when gather news, > But duli seems feel bad, and give herself some pretext, which I > regretted. I known about, indeed, Duli cannot make herself calm at > some case, such as audience's speaking. Win or Lost, from nature, NOT > so important, The key is participating. For me, who should believe > himself. Enjoy 2008 BEIJING. > Years ago, JSON out, give me some hint. We talked about quote symbols. > I hope remove no-use quotes in text. because the full world people > both type the key " at keyboard, that is a BIG huge waste for human > time.:) > Last year, Another project, from AU friends(name forgot), make a new > language, it very same like with my thoughts, and it can focus CSS, > because the AJAXing. Before that I not intrest in CSS. After, I make a > new language too by employing ANTLR. I first apply for ant build file. > Months ago, E4 hot. at meanwhile, I need a UI builder, so I dive into > CSS sea. at this time, I feel, while CSS strange and why I accept it > before? My other application give me an answer, it mix > responsibilities. I not participated CSS forum. maybe I should. IMO, > CSS self, in CHINA says, not a man, not a ghost. > So, I said, maybe not only the parser.:) > > And I still wanna hear Steve about legacy of SWT.:) > Thank you. > > Regards, > Qinxian > > 2008/8/9 Kevin McGuire <[EMAIL PROTECTED]>: > > > > I'm not sure why we'd want to write our own SAC parser. Its a lot of work > > and there are clearly existing technologies which, while maybe not > perfect > > fits, are better than starting from scratch. > > > > I'd much rather work with an existing community supporting Flute or Batik > > (assuming such communities exist, the Flute files are all 2002 so not > clear > > if its dead code or not). Just as with Eclipse, you see if the community > is > > open to making the changes you need. If they are, you help make those > > changes. This gets you the technology you need, and meanwhile furthers > that > > community. Everyone wins! And its a very efficient use of developer > > resources which are always scarse. I'd rather spend those cycles doing > > something more specific to Eclipse (like nice style sheets, like a UI > model, > > etc.). > > > > Regards, > > Kevin > > > > > > > > > > "向雅" <[EMAIL PROTECTED]> > > Sent by: [EMAIL PROTECTED] > > > > 08/08/2008 05:30 PM > > > > Please respond to > > E4 developer list <[email protected]> > > To > > "E4 developer list" <[email protected]> > > cc > > Subject > > Re: [eclipse-incubator-e4-dev] CSS namespaces > > > > > > > > > > Yes, and maybe not only a parser. > > > > SWT burden lots of legacy, which I not known about, and nice to hear > > details. > > > > 2008/8/9 Kevin McGuire <[EMAIL PROTECTED]>: > >> > >> Thanks for moving the comment to this thread. I still don't understand > >> what > >> you are saying though :) > >> > >> Do you mean we should implement a CSS parser from scratch rather than > use > >> batik or flute? > >> > >> Also not sure about your comment on SWT. It has lots of legagy burden, > >> Steve will tell you! > >> > >> Regards, > >> Kevin > >> > >> > >> > >> > >> > >> "向雅" <[EMAIL PROTECTED]> > >> Sent by: [EMAIL PROTECTED] > >> > >> 08/08/2008 12:56 PM > >> > >> Please respond to > >> E4 developer list <[email protected]> > >> To > >> "E4 developer list" <[email protected]> > >> cc > >> Subject > >> Re: [eclipse-incubator-e4-dev] CSS namespaces > >> > >> > >> > >> > >> Since the current CSS shoes not fit our feet, why not consider a fully > new > >> CSS? > >> > >> And SWT has not any legacy burden and weight. > >> > >> > >> 2008/8/9 Kevin McGuire <[EMAIL PROTECTED]>: > >>> > >>>> Hi, > >>>> > >>>> Angelo brought up CSS namespaces, I think this is an important topic > >>>> that hasn't been discussed here yet. > >>> > >>> Sigh... yes. > >>> > >>>> The question is how to specify > >>>> custom widget types in CSS. With SWT, the widget names are > unambiguous, > >>>> but custom widgets can involve name collisions. > >>>> > >>>> Using CSS namespaces would be an option, although I would then opt for > >>>> using a default namespace for SWT to avoid clutter. The CSS could look > >>>> like this: > >>>> > >>>> @namespace "org.eclipse.swt.widgets"; > >>>> @namespace my "my.name.space"; > >>>> > >>>> Label { > >>>> color;red; > >>>> } > >>>> > >>>> my|Label { > >>>> color;red; > >>>> } > >>>> > >>>> On the other hand, some frequently used SWT widgets live in > >>>> "org.eclipse.swt.custom" (CLabel, CCombo, CTabFolder, ...), so those > >>>> would have to be prefixed as well (which I somehow dislike): > >>>> > >>>> swtcustom|CLabel { > >>>> color: blue; > >>>> } > >>> > >>> Agree, I dislike it too. It's annoying to clutter the typical case (SWT > >>> widgets, regardless of whether they are custom or not). > >>> > >>>> Moreover, CSS 3 is not yet widely adopted and the available parsers do > >>>> not support it out-of-the-box. > >>> > >>> Good point. > >>> > >>>> An alternative to CSS namespaces could be some kind of mapping between > >>>> widget classes and CSS element names. > >>> > >>> I think this is a reasonable approach. Extended widgets outside of SWT > >>> would > >>> need some form of qualified name, not so much to prevent clashing with > >>> SWT > >>> since presumably everyone avoids that, but to prevent clashing with > each > >>> other. The element names can be whatever we want them to be, since its > >>> our > >>> code that'll do the mapping from CSS to widget method calls. So we > could > >>> solve it without resorting to CSS name spaces, for example by requiring > >>> that > >>> extended widgets register their names with us in some qualified fashion > >>> (e.g. NebulaGallery). Kinda hacky but would work. > >>> > >>> Kevin > >>> > >>> _______________________________________________ > >>> 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 > >> > >> > >> _______________________________________________ > >> 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 > > > > > > _______________________________________________ > > 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 > >
_______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
