Also, since this is adding new API, could you add examples and unit tests?
I don't see the new properties in the generated C# files (I was expecting to find a Content property in the Efl.Ui.Button class, instead of the SetContent() and GetContent() methods).

Ouch! I am starting to feel extremely tired of all these name collisions...

I do not like the Efl.Text.PropText because then ALL properties will need the Prop prefix for consistency.
I would rather change the type name (to TextContainer, TextHolder, TextWidget, or whatever).

Another alternative would be to make - in C# only - interfaces have the I prefix again (Efl.IText), like MS's coding style recomends. To avoid those "exceptions", all interfaces would follow this scheme.

I know I always ask for the same thing but, before making a decision, can we know how many clashing properties do we have, and how many have no problems? With a little pyolian or lua magic maybe? 😊

Only renaming the interfaces won't be enough. As per IRC discussion, these three properties have conflicts: Efl.Ui.Text.Text, Efl.Input.Key.Key and Efl.Input.Hold.Hold. I guess the easiest solution is to just rename either the property or the type (whatever is easier) instead of trying to come up with a clever C# trick. I'm working on a proposal.

Only renaming the interfaces won't be enough. As per IRC discussion, these three properties have conflicts: Efl.Ui.Text.Text, Efl.Input.Key.Key and Efl.Input.Hold.Hold. I guess the easiest solution is to just rename either the property or the type (whatever is easier) instead of trying to come up with a clever C# trick. I'm working on a proposal.

Meanwhile, as the patch just adds new functionality, we could merge it, and once these three properties are dealt with a new commit would remove them from the blacklist and turn the Getters/Setters private.

Meanwhile, as the patch just adds new functionality, we could merge it, and once these three properties are dealt with a new commit would remove them from the blacklist and turn the Getters/Setters private.

OK, I agree, let's proceed with this. I confirm make, make check and make examples work for me, and the new C# classes have the expected properties available. I cannot review the code, though.