Re: TimingFramework triggers for Trident - Let's try again

[Kirill Grouchnikov <kirillcool@yahoo.com>]

Hi Remy

Thanks for starting the conversation about the triggers. In general, i do want Trident to be a general purpose animation library for Swing applications. At the present moment, all Trident demos are Swing apps, since it's most comfortable to me, produces nice videos and is, frankly, a good match for the animation domain in general. There are quite certainly a few Trident built-in features that target Swing - support for SwingWorkers in scenarios and running stuff on EDT.

However, as a long term plan i do want to refactor the Swing-specific functionality to a separate add-on library. Then, a similar library will be created for SWT, and both will serve as sample add-ons for additional interested Java-based UI toolkits (Pivot, perhaps).

As such, i would rather not fold the Swing triggers into the core library now, but suggest opening a new project and maintaining it until the rest of Swing-specific code in Trident is moved there.

To your other questions - yes, the timeline state is changed asynchronously in the main timeline engine thread. This is by design, and there are still a few issues there that need to be addressed - but in general you shouldn't expect the state to change immediately after calling the relevant Timeline / TimelineScenario APIs. Specifically in your test code, you potentially have a lot of timelines all competing over the same property of the same object - and not starting from the current value as it is at the point when the trigger is activated (but rather start from the current value at the point the timeline was created).

And i don't have immediate plans to allow playing a timeline from the specific position - unless i see a clear need from a real scenario.

Thanks
Kirill