@woohyun
As a part of T7653 this interface can be removed completely and moved into efl_access_object. Additionally events can be refactored into regular methods, so instead of "window,created" we will have something like window_created_emit method or just emit with some parameter. Is this acceptable?

Currentrly, Efl.Pack extends Efl.Container.
And Efl.Pack includes "unpack" which seems almost similar with "content_remove".

I also think this does not have any problem. Let's move this to "Stabilized". :)

Plus, I'm not sure why this is separated with efl_access_widget_action.eo.

elm_actions_get(of efl.access.widget.action) returns "Efl_Access_Action_Data * ",
and actions_get(of efl.access.action) returns "Eina_List * " of action names....

Those are special set of events for efl_access_object_event_emit.
And the method looks ... static one. (i.e. not a method for a specific object)

I don't think efl_ui_layout_part is needed anymore because it is just the same with efl_ui_widget_part now.
Do we have any problem after removing it ?

Currently, only "Efl.Ui.Widget" and "Efl.Ui.Layout_Part" are implementing this interface.

If @cedric @felipealmeida , and @SanghyeonLee don't have any objection on this definition, I think there would be no problem.

If @cedric @felipealmeida , and @SanghyeonLee don't have any objection on this definition, I think there would be no problem.

@zmike
Ok ~ I got your point well, and also check T7436 together.
Thank you !

Then, why are we handling legacy things now ?

One question.
Do we need to handle legacy eo files (for example, elm_xxx.eo, evas_xxx.eo, and so on) now - even those will not be bind to other languages ?

I think this interface looks good, but I'm not sure whether we need to support edje features in efl_ui_image.eo.

I think this interface looks good, but I'm not sure whether we need to support edje features in efl_ui_image.eo.

I think this interface looks good, but I'm not sure whether we need to support edje features in efl_ui_image.eo.

I think Efl.Ui.Factory needs to include "create", "release" (and "created" event), and "model_connect" needs to be included to another interface (or class).
I've heard from @SanghyeonLee that MVVM related things are still in changing, so please check this task together :)

Update elm_code_widget_text.c to free allocated memory

In D7801#138165, @zmike wrote:

This commit log should use the elm: prefix on the first line.

update commit message

Change the commit message

Remove efl.io.* implementing from efl_app

Could you check if this task is ok with following patch (D7747) ?
https://phab.enlightenment.org/D7747

Thanks for giving an answer.
#1 As you described in T7514 like :
reading and writing to the task is feeling a bit weird, and is not really documented what it is supposed to to, in efl_app this is writing to the console, which is a lot complexer with c#&efl.io.writer, than a simpler Console.PrintLine("asfd")

In T7597#129790, @bu5hm4n wrote:

Undefined API!:

eolian: efl_loop.eo:7:1: partially implemented function 'closed' (originally defined at efl_io_closer.eo:35:13)
eolian: efl_loop.eo:7:1: unimplemented function 'can_read' (originally defined at efl_io_reader.eo:39:13)
eolian: efl_loop.eo:7:1: unimplemented function 'can_write' (originally defined at efl_io_writer.eo:40:13)
eolian: efl_loop.eo:7:1: unimplemented function 'close_on_exec' (originally defined at efl_io_closer.eo:52:13)
eolian: efl_loop.eo:7:1: unimplemented function 'close_on_invalidate' (originally defined at efl_io_closer.eo:68:13)
eolian: efl_loop.eo:7:1: unimplemented function 'close' (originally defined at efl_io_closer.eo:18:9)
eolian: efl_loop.eo:7:1: unimplemented function 'eos' (originally defined at efl_io_reader.eo:49:13)
eolian: efl_loop.eo:7:1: unimplemented function 'read' (originally defined at efl_io_reader.eo:19:9)
eolian: efl_loop.eo:7:1: unimplemented function 'write' (originally defined at efl_io_writer.eo:19:9)

I'm wondering how we will handle this unimplemented things.
What I can only think is that separating interface properly if those are not something that have plan to be implemented soon.
(Or removing some interfaces if necessary from the class)

Do you have any plan to auto-remove a duplicated word between @legacy_prefix and @property name ?

Today, I can get following errors when push "quit" button.
(of course, you need some changes on the example codes to avoid build errors)
(I executed the sample with "mono")

I think we can make a list of constants + enums in EFL. And then, let's think which are needed to be set as global.

I've added @protected and @beta in the description for better understanding.

I know you are very busy, but -
please care about this problem together :)

Some of above classes include lots of definitions it them.
For instance, "Efl.Ui.Widget" and "Efl.Canvas.Object".

I'm wondering the goal of this task.
Is this task to manage commits something like https://phab.enlightenment.org/rEFLbbbdfbecc4ecafc25841fc1b36d82916f5db6e0e ?

ping ? Could you check above question ?

@larryolj
ping ? Could you check above question ?

Could you check this task ? I also agree with JackDaniel.

Could you share the progress of this work ?

Do we have a way something like ...

I think customizing for Tizen could be discussed privately.
Except that, what are left for this task ?

@cedric welcome back :)
@Jaehyun_Cho

I also agree with @lauromoura that we don't need to wait for the works of @lauromoura.
Eo class inheritance refactoring should be done independently with his C# binding works.

I agree with the opinion of @bu5hm4n if the way that can make you happy can not be realized soon.
If you have some idea about how to fix (or improve) the bad construrctor system, could you share your idea here ?

Please check inline comment ~

Could you explain how to check the results for automated test cases In devs/felipealmeida/tct ?

@felipealmeida
We only need to include the methods which are "implemented" by the specific class.
That is, we don't need to include the method "not implemented".

@felipealmeida
Could you take care of the case of "efl.ui.Button should be changed to Efl.Ui.Button" together ?
Plus, will you update this to the master branch directly ?
Or, if you are managing another branch for this work, please share the branch name.

Please give a feedback whether to keep this patch or not.
I think we already have another way to communicate for this subject.

Could you give a feedback on this ?

This was a prototyping of new theme for efl_ui_xxx. And I can abandon this because it's already applied by @singh.amitesh.

Could you give a dicision whether to keep this patch or not ?

@eunue
Could you abandon this patch ?

I hope this patch would be updated together with new patch which introduces new MBE class.

@cedric
Oh. ok :) Then, everything is good.

This work includes simplify efl_ui_slider (it includes too much feature inside as a default slider class).
Could you explain why this thing should not be applied on master ?

I've added some inline comments.