Hi Gorken, We picked Batik because well that's what we have in Orbit :) I just wanted *some* SAC parser so we could get things working. Flute is an interesting choice and doesn't drag in the world but we'd have to do the CQ dance to get it into Orbit.
Aside from footprint, what would influence my decision personally is whether there was an active community behind one or the other. At present I can't really tell if there is for either. Flute seems dead based on package date. Do you have any insight? Removing dependencies on common-logging would be good, yes please contribute! Regards, Kevin "Gorkem Ercan" <[email protected]> Sent by: [email protected] 12/16/2008 01:47 PM Please respond to E4 Project developer mailing list <[email protected]> To "E4 Project developer mailing list" <[email protected]> cc Subject Re: [e4-dev] JDK level for e4 work? I actually replaced Batik with Flute when I was doing my trials, as you said it pulls in too much dependencies. Is there a particular reason that flute is not the default parser? I have also removed all the dependencies to the commons-logging from Eclipse code (can contriubute those back if you want to). I am also concerned about the footprint but I figured that would be an area we can help with. -- Gorkem 2008/12/16 Kevin McGuire <[email protected]>: > >> eSWT community is very much interested in those capabilities as well. >> Of course, eSWT has some additions and removals compared to SWT, but I >> think up to the Control hierarchy they are very similar to each other. >> When I was adopting the css engine the biggest missing piece was the >> cursor support. I think we will definitely need to create (either as >> part of e4 or ercp project) a plugin like org.eclipse.e4.ui.css.eswt >> for eSWT and one for eJFace like org.eclipse.e4.ui.css.ejface. Those >> can easily be based on the org.eclipse.e4.ui.css.core. > > Yes I agree this would be how we'd structure it. > >> However the >> best would be to have org.eclipse.e4.ui.css.swt.core which supports >> the hierarchy up to Control. > > Hmmm, that's probably not too big a deal, we'd need to look more closely at > it. And there's likely code to be shared which isn't associated with the > widget hierarchy, like say the mapping of color names and font names to > values, etc. > > On the practical side, since targetting a lower JDK level and splitting the > plugins along certain paths for the eSWT > community is work, this makes sense iff the eSWT community is committed to > contributing. > > Aside from all this, are there footprint concerns for using CSS in embedded? > At present the CSS work isn't small (our code), and there are quite a > number of dependencies. Batik isn't structured in a CSS consuming friendly > manner and pulls in tons. Plus I have no idea if the required JDK levels > for all those dependencies match what you need. Have you investigated these > aspects? I gather from your comments you have some previous experience in > applying Batik to embedded. > >> Speaking of new capabilities, we have already experimented some with >> animations and css engine and very interested on the declarative UI >> but there is an area that we need to enhance eSWT to that I am not >> sure if it would interest the e4. We are working to get Multi-touch >> and gesture recognition to eSWT. I will gladly do that work as part of >> e4 if it is found valuable to do so. > > I personally would find the Multi-touch and gestures work quite interesting > (!!) but not sure of the interest match for e4. > > Kevin > _______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev > > _______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
