@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: [email protected] [mailto:[email protected]] 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 <[email protected]>
To: E4 Project developer mailing list <[email protected]>
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

_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev

Reply via email to