In D10615#199506, @segfaultxavi wrote:

However, if we finish task T8474, we could have only one animation_start() method with default values, so in C# you could use StartAnimation(anim) or StartAnimation(anim, speed, starting_pos). I think this would be the nicest solution.

To revert an animation, in C#, you just need to do:

obj.StartAnimationFull(old_anim, -1.0, obj.AnimationProgress);

This is exactly required for C#!

In D10615#199493, @lauromoura wrote:

This is already done for all @move Efl.Object parameters, like setting the manager in the Container and setting the animation in this patch.

@segfaultxavi @bu5hm4n
I missed asking you one more thing in the original comment.

In D10615#199480, @lauromoura wrote:

As StartAnimation receives their animation object by @move, the C# binding will automatically call efl_ref for it.

@segfaultxavi @bu5hm4n
Thank you very much for the comments! :)

I share the collected opinions about refactoring of Canvas Animation as follows.

I am afraid I need some more time (1 or 2 days) to give you opinion about this animation refactorying work.

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).

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.

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

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.

In 1.23 release, we opened Efl.Ui.Alert_Popup without @beta but we still kept Efl.Ui.Alert_Popup_Part with @beta.

Seems ok to me.
Same comment with @zmike about "center_pointer".

Basically I like the idea (P) animation :)

Renamed efl_ui_types.eot to efl_ui_drag_types.eot only.

In D10370#193282, @zmike wrote:

In D10370#193272, @woohyun wrote:

Except below three - I added @since 1.23 to all none-beta classes.
After getting the proper answers, I'll update this patch (or create new diff).

1. elm_interface_scrollable.eo
   • Below two enums should be marked as @beta or @since 1.23 ?
     • enum Elm.Scroller.Policy
     • enum Elm.Scroller.Single_Direction

I think these are much older than that?

elm_interface_scrollable.eo.h and elm_interface_scrollable.h are included in Elementary.h only if EFL_BETA_API_SUPPORT is defined.
Therefore, it seems that @beta is right for the above enums as this patch does.

• 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?

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

fix typo

Thank you, I think you are right.

Abandon unavailable patches.

Abandon unavailable patches. The alternative patch exists.

Abandon unavailable patches.

Abandon unavailable patches.

This patch is not appropriate and the alternative patch exists.

yes, thank you :)

@bu5hm4n
Thank you for your opinion. I agree with you.
Then the following cases should be modified to keep consistency with other part names.
"efl.text.title", "efl.rect.background", "efl.text.status", "efl.swallow.event", "efl.content.hotspot", "efl.spacer.opaque", "efl.spacer.content"

What do you think about using edc part type as a namespace?
i.e. "efl.text.title", "efl.rect.background", "efl.text.status", "efl.swallow.event", "efl.content.hotspot", "efl.spacer.opaque", "efl.spacer.content"

also replaced missing one

I categorized the signal names into 4 groups as follows.
I want to discuss how we can categorize signal types. If we are able to categorize signal types, then it would be helpful to choose the right name for it.

@zmike
Let me explain the each purpose of "start", "stop", "play" as far as I know.

@zmike
I introduced this patch because many methods of Efl.Player are not fully implemented in its inheriting classes. It is related to T5719.
Is it ok if classes do not fully implement their interface's methods?

@lauromoura yes! thank you :)

@bu5hm4n Thank you for your reply.

Is it ok if this is submitted?

Is it ok if this is submitted?

In EFL C#, autohide and win_type are necessary to implement a C# application.

free iterator

@zmike
Hello~ Do you know the reason why @property win_type, @property autohide are still marked @beta?
e.g. @property win_type is marked @beta because related wayland feature can be changed later?

@lauromoura
As I mentioned in D10001, some words are used as verb in some method names and they are used as noun in other method names.
To resolve this problem, we may need to introduce a new eo syntax.

add ref T8225

Fixed not to keep array and rebased

fixing memory leak in efl_ui_widget_factory.c is included

rename the error name

update indentation