change Efl.Ui.Text_Cursor_Selectable to Efl.Ui.Text_Selectable

@bu5hm4n
Thank you for the feedback :)
I wanted to apply this change before release but as you say let's wait until release because these interfaces are @beta ;)

What do you think about removing the namespace "Csharp"? (if so the file name is also changed to efl_application.cs)

Please give some comments on this patch.

@zmike
ok~ then please suggest a new name :)

rebase has been applied

The original name Efl.Ui.Stack is preserved.

Could you tell me why memory initialization is required only for debugging mode?

D7888 is reverted since it breaks the backward compatibility. So D7603 is also reverted since it is based on D7888.
Now a new proper patch is required instead of D7888 to fulfill D7603.

Since we should revert D7888, this patch is also required to be reverted just for now.
After a proper patch is applied instead of D7888, then I think that we can submit this patch again.

I am afraid this patch breaks the backward compatibility.
Please check the Popup -> popup-center-text in elementary_test. (text is not displayed.)

This is a minor suggestion of moving code inside the conditional expression.

Regardless of this patch, what do you think about changing method name "create" in Efl.Canvas.Gesture.Recognizer to "gesture_create"?

I have checked the code and tested the functionality.
And I found out that win cannot add gesture event.
Is it originally intended?

Are the other glayer values not required for now?

rebase

Could you please mark @beta for scroll methods?
As @bu5hm4n said, it may be not the right place for these methods..
I think that @eagleeye will check if it is possible to move these methods out of Efl.Ui.Widget. (T7714)

IMHO, I think the following properties/methods/events are essential for Efl.Ui.Win.

I don't mind if you remove the properties/methods/events which you mentioned that those are not used or are related to only X11.
It is fine if those are preserved in legacy at least :)

It seems that all the properties and methods are required to be marked @beta for now :)
(P) theme may be required to change its values (style) based on @bu5hm4n and your opinion.
(P) automatic_theme_rotation and (M) theme_rotation_apply are submitted recently. So it seems that it requires some time to check them.

2: This property is removed, so there is no point in renaming it to this ?

Sorry about this. I missed that the property is removed in this patch.

Thank you for your opinion :)
(I think that you vote for 1. Efl.Ui.Stack)

I replied your comments.

I think that the backward compatibility is not kept here.

Should we use the term 'orientation' in this case? (As you know, the term 'rotation' is specifically used for animation in many other platforms)

I think that the property 'rotation' is not that useful for Efl.Ui.Win.

I think this is a typo.

rebase

Thank you for sharing your idea :)
I do not insist to separate those static methods from Efl.Access.Object.
I want to know your opinion.

I think there is no problem on your original plan in T7653 (refactoring Efl.Access.Object to be a regular class) based on C# perspective.

do we need to modify src/bin/elementary/test_efl_gfx_map.c to src/bin/elementary/test_efl_gfx_mapping.c as well?

Thank you for suggesting your new idea :)
However, I am afraid that the downsides are bigger than now I think..

Thank you for the link https://www.c-sharpcorner.com/UploadFile/b942f9/how-to-create-mixin-using-C-Sharp-4-0/ !!
It is brilliant! :)

efl_ui_cursor.eo still exists.

As I checked ecore_wl2_display_screen_size_get and ecore_wl2_output_dpi_get, currently the property "screen_size" is used as a resolution. (not physical millimeters or inches).
"screen_size" is received from width(width of the mode in hardware units) and height(height of the mode in hardware units) of mode in https://people.freedesktop.org/~whot/wayland-doxygen/wayland/Client/structwl__output__listener.html

fix to display value correctly

I've submitted the revert patch. (f23f3074daa3e9da5b37cc168df5d6b003e0ec62)
Thank you all~

Is there any reason why relative layout itself becomes a child?

Should we implement Efl.Pack or not to call layout,updated event?

@stanluk
As you know, currently EFL C# converts mixin in .eo to interface in .eo.cs.
This works well but as I told you, app developers may be confused when they investigate or debug the C# interface which is originally mixin in .eo.

@bu5hm4n
Thank you for the opinion.
If @segfaultxavi and @cedric do not disagree, then I will push a revert of this patch.

Thank you :)

It seems that many legacy eo files are considered in P265.
(e.g. elm_xxx, evas_xxx, edje_xxx, ecore_xxx)

as I understand, this patch is required because tab is packed to elm_box.
if so, could you add FIXME comment on here?

@segfaultxavi @cedric
Sorry, my example was incorrect as @cedric said.

@bu5hm4n
I almost made a big mistake! Thank you very much! :)

fix incorrect variable name

The declaration of "new_data" is moved to the top of the scope.

As you said, Efl.Canvas.Animation does not have its own animation properties (e.g. scale, alpha, etc.)
However, with Efl.Canvas.Animation_Player, Efl.Canvas.Animation can be used as a custom animation.
e.g.

Could you add prefix "efl_ui_list_view:" to the commit title?

I am not sure about some codes if they are correct.
Please check the comments.

I think we can separate the cause of this task into 3 cases.

@eagleeye
could you add unit test for this as @zmike mentioned?

To me, this patch is acceptable.
Can I submit this patch? :)

update code

I think my second comment is required to prevent memory leak.
I am not sure about my first and my third comments.

Thanks 211064113104702b2c6bd279e9e8a04ee0e8254a :)
But when I try to print all the unimplemented warnings by using the above commit, build error causes not to print all the unimplemented warnings.

comments for rebase