actor: Implement implicit animatable properties
authorEmmanuele Bassi <ebassi@linux.intel.com>
Thu, 15 Mar 2012 11:09:11 +0000 (11:09 +0000)
committerEmmanuele Bassi <ebassi@linux.intel.com>
Thu, 15 Mar 2012 17:01:12 +0000 (17:01 +0000)
commit67113ed690bed69fe182f675d0951bf21047e026
treefc9e43c099497ed8c0c977783408c20f25aa8913
parent40bcbf9c0d5db711b2bce47459cca40e2cf27266
actor: Implement implicit animatable properties

Clutter is meant to be, and I quote from the README, a toolkit:

  for creating fast, compelling, portable, and dynamic graphical
  user interfaces

and yet the default mode of operation for setting an actor's state on
the scene graph (position, size, opacity, rotation, scaling, depth,
etc.) is *not* dynamic. We assume a static UI, and then animate it.

This is the wrong way to design an API for a toolkit meant to be used to
create animated user interfaces. The default mode of operation should be
to implicitly animate every state transition, and only allow skipping
the animation if the user consciously decides to do so — i.e. the design
tenet of the API should be to make The Right Thing™ by default, and make
it really hard (or even impossible) to do The Wrong Thing™.

So we should identify "animatable" properties, i.e. those properties
that should be implicitly animated by ClutterActor, and use the
animation framework we provide to tween the transitions between the
current state and the desired state; the implicit animation should
happen when setting these properties using the public accessors, and not
through some added functionality. For instance, the following:

  clutter_actor_set_position (actor, newX, newY);

should not make the actor jump to the (newX, newY) point; it should
tween the actor's position between the current point and the desired
point.

Since we have to maintain backward compatibility with existing
applications, we still need to mark the transitions explicitly, but we
can be smart about it, and treat transition states as a stack that can
be pushed and popped, e.g.:

  clutter_actor_save_easing_state (actor);

    clutter_actor_set_easing_duration (actor, 500);
    clutter_actor_set_position (actor, newX, newY);
    clutter_actor_set_opacity (actor, newOpacity);

  clutter_actor_restore_easing_state (actor);

And we can even start stacking animations, e.g.:

  clutter_actor_save_easing_state (actor);

    clutter_actor_set_easing_duration (actor, 500);
    clutter_actor_set_position (actor, newX, newY);

    clutter_actor_save_easing_state (actor);

      clutter_actor_set_easing_duration (actor, 500);
      clutter_actor_set_easing_mode (actor, CLUTTER_LINEAR);
      clutter_actor_set_opacity (actor, newOpacity);
      clutter_actor_set_depth (actor, newDepth);

    clutter_actor_restore_easing_state (actor);

  clutter_actor_restore_easing_state (actor);

And so on, and so forth.

The implementation takes advantage of the newly added Transition API,
which uses only ClutterTimeline sub-classes and ClutterInterval, to cut
down the amount of signal emissions and memory management of object
instances; as well of using the ClutterAnimatable interface for custom
properties and interpolation of values.
clutter/clutter-actor-private.h
clutter/clutter-actor.c
clutter/clutter-actor.h
clutter/clutter-private.h