Re: Why using Tweener for animations?

[Giovanni Campagna <scampa giovanni gmail com>]

On Thu, Jul 29, 2010 at 9:43 AM, Dan Winship <danw gnome org> wrote:
> On 07/29/2010 01:02 AM, Giovanni Campagna wrote:
>> I know, it may have been discussed before, but I'm still puzzled by
>> this. Clutter comes with a powerful and extensible animation API, yet
>> the Shell uses Tweener, which is pure JS.
>
> ClutterAnimation didn't exist when we started, and now we're used to
> Tweener. That's mostly it.
>
> Also, Tweener is pretty convenient to use, and ClutterAnimator probably
> wouldn't be quite as easy. Although that might be fixable with some JS
> wrappers?

It turns out ClutterAnimation cannot be used in JS, due to the brokennes of Gjs.
(clutter_actor_animatev throws before calling the C function,
clutter_animation_bind returns null, ClutterInterval cannot be
constructed because GTypes are not seen in JS code)

>> Currently,
>> St.Tooltip uses ClutterAnimation, but has been declared broken.
>
> StTooltip's animation is broken because the effect sucks, not because
> the code is bad. We do use ClutterAnimation in a few places in St.
>
>> The main advantage of using Tweener (as I see it) is that it allows
>> special properties, which is overcome by implementing
>> ClutterAnimatable in the actor involved.
>
> So to implement workspace_relative, we'd have to create a special StBin
> subclass to put the window clones in? That would be a little bit lame...

It wouldn't, if classes were inheritable from JS...
(else, you could use the same hack as Shell.GenericContainer: signals)

>> PS2: of course, if the answer is "kill Tweener", I'll be glad to help.
>
> It might be useful to see what some piece of existing code would look
> like ported to ClutterAnimation.

In theory,
Tweener.addTween(actor, duration, { property1: value1, property2: value2 });
should be replaced by
actor.animatev (mode, duration, ['property1', 'property2'], [value1, value2] );
Unfortunately, that does not work because of binding problems.

>
> -- Dan
>