| 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