| Re: [e4-dev] Re: Trident (was: animations) |
@Kirill @Boris,
I am excited to see this topic going on. As soon as a trident version is available for e4 RCP apps I would volunteer to add some animations to my e4 contacts demo. When doing that I could provide Kirill with concrete feedback.
Best regards,
Kai
From: e4-dev-bounces@xxxxxxxxxxx
[mailto:e4-dev-bounces@xxxxxxxxxxx] On Behalf Of Kirill Grouchnikov
Sent: Freitag, 4. Dezember 2009 06:02
To: E4 Project developer mailing list
Subject: Re: [e4-dev] Re: Trident (was: animations)
Hi
Boris
Thanks for the comments. It looks like we are talking about minor issues - how
Trident is implemented. That's a lot of valid points that we can discuss in
this list or in the project mailing lists.
Looking beyond the technical details of singletons, properties files and the
specifics of constructing timelines, i would like to have some people looking
at the existing samples shipped with Trident and Granite to see how it feels to
a person not deeply familiar with the library. Trident has a few simple
examples - such as animating the FG color of a radio button on mouse rollover,
as well as more complex application such as Granite.
Along the way i have run into a number of limitations in SWT as far as the
animations go. For example, i wasn't able to animate the FG color of a button.
Not sure if this is because of SWT or the native APIs. Another example is in
JFace - wanted to do animations on table rollovers / selections, but seems that
the color provider infrastructure is not dynamic. Once the cell is configured
to use the specific BG color, it cannot be dynamically changed - or maybe i'm
missing something.
What i'm saying is that SWT / JFace might need internal changes no matter which
animation library (third-party or written from scratch) is chosen. As you have
said, it would be great to have a few demos trying Trident and seeing how the
APIs feel, and what limitations in Trident / SWT are found - to get the ball
rolling.
Thanks
Kirill
From: Boris Bokowski
<Boris_Bokowski@xxxxxxxxxx>
To: E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
Sent: Thu, December 3, 2009 2:29:06 PM
Subject: Re: [e4-dev] Re: Trident (was: animations)
Hi Kirill,
> * Support for each UI toolkit is less
than 10KB in the final jar. So
> the size shouldn't be a problem.
> * Trident gracefully degrades when the specific UI classes are not
> in the path (specifically relevant for SWT and Android). So you
> shouldn't be getting any runtime exception on missing classes.
Sounds good but I'd still prefer to only
have the SWT support configured. Running less code is a good thing unless you
really need it. For example, we've seen cases where just referencing Swing/AWT
classes ends up starting the AWT UI thread, which I'd like to avoid until you
are actually using Swing/AWT for real. (This is just an example - I'm not
saying that this happens when you use Trident, I haven't checked and it
probably doesn't.)
> If given that you still want to strip away these classes, i can
> tweak the build.xml to produce:
>
> * The full runtime jar
> * The core jar without any UI specific classes
> * "Plugin" jars - one for each UI toolkit
Sounds good (but in which jar would the
trident-plugin.properties file be?)
> About Timeline / SWTTimeline. I wouldn't necessarily want to see an
> over abundance of UI-specific extensions of Timeline classes. If you
> want to remove the declarative mechanism for some reason, you can
> call TridentConfig.getInstance().addUIToolkitHandler somewhere in e4
> / app code. Trident will figure out if the specific timeline needs
> special UI support based on the main object of that timeline.
To explain myself... I have a built-in
aversion against using the Singleton pattern :-), and don't see why it would be
needed in this case if you allowed subclasses like SWTTimeline. But maybe I am
missing something.
> About OSGi support - let me know what entries are required in
> manifest and i will add them in 1.2dev branch.
Thanks! Will send a separate email with
details, hopefully tomorrow.
Boris