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

[<remy.rakic@gmail.com>]

Very nice kirill.

Everything looks smooth.

Regarding keyframes in animation tools. I don't have specific links in
mind. However, i can tell you how they work there, in my experience. A
lot of the times, it's the only way to do animations, since they allow
both complex and basic scenarios. I find that point interesting enough
to be mentioned.

Visually it works like this. The visual timeline component allows you
to set the curent time. The design surface shows the state of your
artwork at this point. Whenever you set another time, by moving the
playhead or play/pausing, or manually. Any modification you make on the
artwork will either automatically be added as a keyframe, or you'll be
able to do so manually.
When you have your keyframes what you need to do most of the time is
setting the interpolation between them. After that it's a lot of
play/pause/stop, move the playhead, change the keyframes, adjust the
interpolation splines, rinse, repeat till you're done.

Regarding the keyframes api, one the one hand you have the fact that it
should be trivial to switch from the timing framework to trident, on
the other, the api was modified a little in Scenario. Chet says the one
in scenario makes more sense for the api, there is now a keyframe
object that holds the time, value, and an optional interpolator (your
timeline ease, but at the property level, which is interesting so you
can have different interpolations on multiple properties within a
single animation, which makes sense) and optional evaluator (the thing
that does the spatial interpolation, linear by default). (fyi what you
call interpolators, they call composers; what you call timelineease
they call interpolators)

A little example that compares the two will probably allow you to make
your mind about both. 

Here's how the alpha of the cool iris use case would look in TF:
(straight from your test :)

KeyValues alphaValues = KeyValues.create(0.0f, 1.0f, 1.0f, 0.0f);
KeyTimes alphaTimes = new KeyTimes(0.0f, 0.3f, 0.7f, 1.0f);
progressTimeline.addPropertyToInterpolate("alpha", new
KeyFrames(alphaValues, alphaTimes));

And here's how it would look in Scenario:
Clip progressClip = Clip.create (5000, KeyFrames.create (this, "alpha",
KeyFrame.create (0f, 0f),
   KeyFrame.create (0.3f, 1f), KeyFrame.create (0.7f, 1f),
KeyFrame.create (1f, 0f)));

Regarding the property themselves, using only property descriptors ties
you to bean properties, ie with a getter and setter method. The trident
user is not able to create his own property animations respecting 1)
his own property syntax eg name(String) instead of setName, 2) his own
property framework (like bean-properties or pulpcore's) 3) create
"virtual" properties and animate them, like some kind of composite
between two values, etc.

I'm not sure it's a big deal, it doesn't hurt me very much, but then
again i'm not a full time trident user (yet ? :)

Oh btw i think it'd be nice to have two trident-plugin.properties,
right now using the swing one depends on swt at runtime, and vice
versa, and trident crashes when they're not both available. Am i
missing something here ?

Thanks
Rémy