In D10615#199494, @Jaehyun_Cho wrote:

Adds @method animation_revert(void) to Efl.Canvas.Animation

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#199492, @Jaehyun_Cho wrote:

In D10615#199480, @lauromoura wrote:

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

@lauromoura
It would be a good idea! We need to check if it would be fine for all other @move cases. (e.g. @property manager of Efl.Ui.Spotlight.Container)
But I think it would be fine for other @move cases as well :)

In D10615#199480, @lauromoura wrote:

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

In D10615#199450, @Jaehyun_Cho wrote:

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

I think this is pretty fine like it is now, there are 2 more things that need to migrate away from player, but that does not block this revision here.

I think API-wise I have no more comments for this patch (pending the end of the discussion).

asdfasdf

its efl canvas now.

renames

Thanks for this analysis of the situation. @bu5hm4n and I have been talking about it and we agree on almost everything, but we'd like to make some clarifications:

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

I propose an unification of all animation flags in D10645 which should clarify things.
If you make this patch depend on D10645 (and rebase) you should be able to rename animation_object to just animation. How does that sound, @bu5hm4n @Jaehyun_Cho @zmike @cedric?

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

more tests, and a simple fix

fix animation. position is now returned *always* from 0.0 to 1.0

In D9717#198289, @YOhoho wrote:

@lauromoura
Is there any reason not to use csc directly?
csc has been available since mono 5.0.0 ( https://www.mono-project.com/docs/about-mono/releases/5.0.0/#c-compiler )

add a example

@lauromoura
Is there any reason not to use csc directly?
csc has been available since mono 5.0.0 ( https://www.mono-project.com/docs/about-mono/releases/5.0.0/#c-compiler )

I put the wrong assembly name for mono...

Rebase and update after D10337 added friendly assemblies

Disregard comments re: mainloop iterate as these tests do require a rendered frame.

tweak item move test coords to pass on CI

IMO, using tags for error is not the best way. A typedef is much better. However, this tag is important for things that are, possibly, platform-specific. So you can tag that a method is not going to be generated for Tizen, for example.

This is breaking travis somehow, still working on getting it to be consistent enough to land...

Hrmm.... then we are in the same situation. There's tags meant for eolian and there's tags meant for the bindings generator, but the guy creating a new EO file does not care about that distinction and will be utterly confused, unless he created the tag.
I mean, if I am creating Eo files and I need a custom tag, then I'm fine, no confusion.
But for the case we were trying to solve (reporting when a bool is indicating an error), I will need to remember that this tag is written differently than all other eolian tags.

In D10432#194891, @segfaultxavi wrote:

1. Use @ in both cases, so user keywords cannot use names already in use by eolian. Downside: if we add more eolian tags in the future, we might break already-existing EO files some people might have created with user keywords.
   
   ....
   
   I like option 1 better. It means that any @tag eolian does not recognize is just stored as a user keyword. This also means that mispellings like @proprety won't be detected.

I am not sure I like the #tag syntax. From the user's perspective, some tags will need @ and some others #, for no apparent reason.

Use eina_hash_population as reviewed by YOhoho.

Added property and class support

You can use eina_hash_population to get the number of hash elements.

This is a partial implementation, but shows how to use on the test. It is still specific to methods only on this diff. But I'll expand to other entities.

Update with support for dotnet core 3.0

Also added a declaration of Efl.ObjectRealized using Efl.Object.NativeMethods as its NativeClass attribute. The hidden class test was failing in dotnet without it, as the class map when marshalling from C was not finding it.

Needs rebase after the release.