Another possibility would be to remove the underlying animation logic
entirely and separate it out.
what-I-mean
The libanim library, for example
(http://github.com/jtdubs/libanim/tree/master) assumes the concept of
animation is unrelated to the actual rendering or modeling frameworks
used. Rather, you set up values to be animated and ask it for the
values at time t. This allows you to do animations live, or render
them frame by frame to some file, etc. It separates concerns.
/what-I-mean
Clutter could use libanim (or similar) and build its clutter-style
animations on top of it. There would be no need for and alpha
function or a timeline.. simply an animation (p.s. I haven't thought
this through).
Jimmy
On Mon, May 25, 2009 at 8:46 AM, Jonas Bonn jo...@southpole.se wrote:
Hi,
I had a short discussion with ebassi on #clutter... we decided I would send
an email detailing what I feel are some weaknesses in the Animation
API/implementation. Thanks for considering this; my thoughts follow:
An Animation currently keeps track of:
timeline
mode
duration
loop
However, these four properties are actually properties of:
i) The underlying Alpha object (mode, timeline)
ii) The Alpha object's timeline (duration, loop)
I am free to manipulate the Alpha object directly; I can call
clutter_animation_get_alpha(...) and then set the Alpha properties directly.
PROBLEM 1: The Animation does not watch the Alpha object for property
changes, so direct manipulation of the Alpha's properties results in the
Animation becoming out of sync with its Alpha. Concretely, this means that
the Animation's timeline no longer mirrors the Alpha's timeline and likewise
for the mode.
POTENTIAL SOLUTION: Watch Alpha for property changes and update Animation
accordingly.
BUT: Why bother mirroring the properties?
BETTER SOUTION: Just defer to the Alpha when querying/updating Animation
properties...
The same goes for the timeline.
PROBLEM 2: I can manipulate the timeline externally, but the Animation does
not watch for changes to timeline properties so the Timeline and Animation
can get out of sync.
POTENTIAL SOLUTION: Watch Timeline for property changes and update
Animation accordingly...
BUT: Again, why bother with the mirroring?
BETTER SOLUTION: Just fall through to the Alpha's Timeline for
querying/updating properties.
As it stands today, when I call clutter_animation_set_timeline(animation,
timeline), then the timeline will be stored in both the Animation and the
Alpha.
PROBLEM 3: The Alpha may have been set externally (e.g. with
_animation_set_alpha(anim, alpha))... it should be made explicitly clear
that setting the Animation's timeline has the side-effect of setting the
Alpha's timeline. (This may surprise the user).
POTENTIAL SOLUTION: Document this.
BUT: Again, why bother storing the timeline in two places?
BETTER SOLUTION: Document explicitly that that animation_set_timeline is
just a helper function that sets the timeline on the underlying alpha. This
way, there are no surprises.
The API currently requires something like the following (note here the two
calls to _set_timeline and _set_alpha with parameter NULL).
anim = clutter_animation_new();
clutter_animation_set_object(anim, G_OBJECT(actor));
clutter_animation_set_duration(anim, 150);
clutter_animation_set_mode(anim, CLUTTER_LINEAR);
clutter_animation_set_timeline(anim, NULL);
clutter_animation_set_alpha(anim, NULL);
interval = clutter_interval_new(G_TYPE_UCHAR, 0, 255);
clutter_animation_bind_interval(anim, opacity, interval);
timeline = clutter_animation_get_timeline(anim);
PROBLEM: If I forget to call _set_alpha, then the animation just silently
fails to do anything. (I ran into this... took me a while to figure out).
SOLUTION: An animation without an alpha is pretty useless... if the
animation has no alpha when the user tries to run it, then we should set up
a default alpha for him. This ties into the following point...
PROBLEM: The two calls to _set_timeline and _set_alpha with parameter NULL
should not be necessary as they are just invoking a default configuration.
SOLUTION: Make clutter_animation_get_timeline() do the right thing by
creating the necessary underlying Alpha and Timeline if they do not already
exist. Then these two calls can go away.
NOTE: (Given this solution) Generally, the underlying Alpha and Timeline
will already exist before clutter_animation_get_timeline is called because
they will need to be created in order to hold the other property values...
see the notes that follow:
NOTES:
_set_duration: requires a timeline, so this function will implicity create
an alpha and a timeline if they are not already set.
_set_loop: requires a timeline, so same as for _set_duration
_set_mode: requires an alpha, so this function will implicitly create an
alpha if one is not already set.
_set_timeline:
