Re: [e4-dev] JDK level for e4 work?

[Kevin McGuire <Kevin_McGuire@xxxxxxxxxx>]

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" <gercan@xxxxxxx>
Sent by: e4-dev-bounces@xxxxxxxxxxx

12/16/2008 01:47 PM

Please respond to
E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>

To	"E4 Project developer mailing list" <e4-dev@xxxxxxxxxxx>
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 <Kevin_McGuire@xxxxxxxxxx>:
>
>>  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
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
>
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev