>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.
It is the limitation of SWT on Windows. yves From: [email protected] [mailto:[email protected]] On Behalf Of Kirill Grouchnikov Sent: Friday, December 04, 2009 6:02 AM 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 Internal Virus Database is out of date. Checked by AVG - www.avg.com Version: 8.5.392 / Virus Database: 270.13.58/2306 - Release Date: 08/16/09 06:09:00
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
