Seems fixed! Thank you!

I think most users will assume that \r \n and \t ARE whitespace characters:
https://en.wikipedia.org/wiki/Whitespace_character

As documentation explains, the string passed to style_apply() is a key=value pairs separated by white spaces.
So I think what we currently doing is violating this information.

The revision i have linked above now contains pause. You can check the example that got added in this revision and press p for pause (press twice for toggle) or press r for reverse, which will reverse the animation, just as you wished to do that. IMO the code in there look super easy and nice. The speed parameter is essential for the reversing, if i remove it again, the reversing code will be way harder. Would something like the revision be acceptable for you ? If yes, then i would continue removing the player object, as this usage as we have it right now is way easier.

In T8288#146873, @bu5hm4n wrote:

1. If pause like this is a *must* have, then we can introduce it to this mixin and support this case. No problem with that. We just have 0 usages of that right now so I saw no purpose in carrying it over (further more, the pause feature in the player object does not work at all like pausing, it will restart the animation from the begining when you unpause it, which is why I said this is totally equivalent to start stop. The problem you are describing is also happening right now in the player class, pausing is resetting the mapping.).

I think "pause" and "resume" are basic functions for animation. It is hard to find framework that support animation without "pause". So I think that we need to support it.
Even though "pause" is not perfectly supported now, I think it would not be a reason why we do not need to consider "pause".
BTW, for now, it seems that "pause" works with Efl.Canvas.Animation_Player without resetting mapping. (elementary_test -> Efl.Animation.Pause ->Pause Animation/Resume Animation)
If we add "pause" to the new mixin, then I am worried if it would look fine by design aspect that supporting animation control functions to canvas object (by implementing new mixin).

1. If pause like this is a *must* have, then we can introduce it to this mixin and support this case. No problem with that. We just have 0 usages of that right now so I saw no purpose in carrying it over (further more, the pause feature in the player object does not work at all like pausing, it will restart the animation from the begining when you unpause it, which is why I said this is totally equivalent to start stop. The problem you are describing is also happening right now in the player class, pausing is resetting the mapping.).

I totally understand the reason of your idea. I think it implies the followings.

1. Set one animation to multiple canvas object.
   • To support this, animation should not support animation controls such as "Start" and "Stop".
2. Support animation simpler.
   • To support this, Efl.Canvas.Animation_Player is removed because it implements way too much methods. And new mixin is introduced with small number of methods.

I implemented the RFC from Xavi above here: D10615 (So we have something to talk about).

Please could you give your thoughts about this discussion? (i.e. Introducing new mixin with animation_start/animation_stop for Efl.Canvas.Object)

After a lot of discussing on IRC with @bu5hm4n I have a better knowledge of the requirements for this.

I am worried that adding additional methods to the new mixin would make the new mixin complicated like Efl.Canvas.Animation_Player unlike the initial purpose.

I am a little bit worried to have this mixin implement Efl.Player that would mean that *every* Efl.Canvas.Object has a playing paused and playback_speed method, which might be very confusing. Additionally, this might collide with other implementations in the Video Canvas Object. So i do not think this is an option tbh.

Can this new mixin Efl.Canvas.Animatable also implement the Efl.Player interface? In this way, the playing, paused, playback_speed etc. properties will all be accessible in the canvas object itself.

Basically I like the idea (P) animation :)

Future are useful and best when it is an one off trigger than can be used to chain a series of other action. In this case, I think animation,end is a valid case of using a future as you might want to trigger another animation or use it as a timeout to do something else. Event are best for something that is repeated with the same action expected as a consequences of that event every time.

Efl.Canvas.Animatable Looks good to me, however, it sounds very made up for this. But it would be totally acceptable for me.
Would everyone be okay with that:

(P) animation //the currently played animation. Re-setting a animation will stop the old one. The value here is @owned (but the parent is never touched).
(E) animation,end //after this is called animation will automatically be unset.

This all sounds very sensible. How would you call the mixin? Something like Efl.Canvas.Playable, Animable or Animatable?
I also prefer the animation property instead of the play_animation method. It's exactly the same, but it allows the user to read back the current value.
Also, why return a future instead of emitting an event? We now have two equivalent mechanisms (futures and events) and we risk creating a lot of confusion if we don't use them in a consistent manner.

I like the idea of the mixin, though I think we probably want to go with something more like animation as a property that can be read and changed to trigger the animations.

RFC Replacement of Efl.Canvas.Animation.Player

So, all of the things raised about Efl.Canvas.Animation.* APIs are solved as far as i can see in the attached revisions.

@Jaehyun_Cho Can you review D10350 ?

• efl_canvas_animation_rotate:
  • Current rotate's cx and cy is double value relative to the pivot object. (e.g. 0.0 ~ 1.0, center is 0.5) So I am not sure if Vector is the correct type for this relative values although value type is the same.

I think Vector2D sounds like the type we want to have for that. Maybe its just me, but i am prefering to have a simple container over two values for the same semantical thing.

Like you said, it may be related to preference. The reason why I am not sure about this is because these parameters have similar values of the parameters of hint_align of efl_gfx_hint.eo.
BTW, I don't have any preference about this case.

I think Vector2D is the correct thing here, my idea would be that the parameters would be in the end (from : Vector2D, to : Vector2D, pivot : Efl.Canvas.Object, c : Vector2D)

Oh, I misunderstood. Now I see. So it is the same as the preference of using Vector2D type.

Mhm, after reading it a second time, i think i am a bit confused here. What is autodel deleting, the animated object, or the player ?

If auto_del is true, then player is deleted when animation ends.

I am actaully a little bit concerend about the amount of objects required something easy as a animation.... esp. with the autodel thing, so you create 2 objects just to delete them. If we publish that like this. Then we have no good way to refactor that later on ... :(

I totally agree with you that we need to reduce the number of objects which are created for easy animation.
I'm sorry I don't understand what you mean about autodel in the later comment. Could you explain please?

In T8288#144489, @Jaehyun_Cho wrote:

@bu5hm4n Thank you for the description :) I replied as follows.

• efl_canvas_animation:
  • I think duration is the same as Efl.Playable.length.
  • Since interpolator has its own factors, I think it should be an object. Can we make interpolator not ownable? Because I think there are some demands that app wants to implement animations with same interpolator. (e.g. Cubic Bezier with the same factors. If Interpolator is ownable, then app should create and set interpolator again and again.)

@bu5hm4n Thank you for the description :) I replied as follows.

@Jaehyun_Cho what do you think about those things ?