I also think it is very meaningful to discuss Error things for EFL.
However, this task has a purpose to define text related interfaces.
Error things need to be discussed over EFL, so that kind of things can be talked in another channel such as irc or mailing thread.
Interface related tasks are normally urgent if we think about the due date (i.e. next release).

This seems good for me. If there would be no more comments in 2 days ~ I'll accept this :)

remove meaningless code and add more test case

If we don't have any other refactoring point on this patch, this looks a bit risky - as the results of your test are showing.
And, I am concerned that applications would be much slower whenever they create more objects while executing.

As everyone here is concerned, it really gives performance problem a lot.
You can check the slowness by executing attached EFL# application easily.
(launching, scrolling, and resizing window .. everything is slow)

Yeah, it should make "finding escape string" be faster.
If there would be no objection (or feedback), I'll accept this patch soon.

I don't think your patch is not working fine.

@felipealmeida @lauromoura
If you have working branch to handle this task, would you share the branch name here ?

I've fixed this issue by D8462.
But I think the magnifier feature in elm_entry has been bad as it has not been worked at all.
Anyway - my patch will fix "infinite recursion and crash" at least.

Thank you for handling this with proper way : ) So, I abandoned.

In T7511#132129, @zmike wrote:

I am now wondering whether we need:

├ (P) indicator_mode
├ (P) keyboard_mode
├ (P) screen_constrain
├ (E) indicator,prop,changed

in the initial stabilization or whether these can remain beta. @woohyun @Jaehyun_Cho

In T7553#131982, @zmike wrote:

I think we should mark all the cursor apis as beta for now; these seem very X11-specific (e.g., Wayland has no cursor "name" property, you just send render buffers to the compositor) and we may want to change it later.

I also agree with this opinion. We can find a better way to get along with wayland.

In T7512#131886, @zmike wrote:

Thinking further, theme should contain style because if they are separate then this will trigger unnecessary recalcs and/or errors when the group and style are applied separately. But I am still not sure of the requirement to keep $widgetname and $subobject separated.

@zmike
I also agree with your point that almost all methods and properties need to be set as beta.
So, we can re-define them all after this release.

In D8017#143552, @bu5hm4n wrote:

@woohyun Yes this is on purpose, for this reason:

Imagine a window with a table, that contains 6 buttons. If you now do:
efl_widget_disabled_set(win, EINA_TRUE); then the window will be disabled, and all widgets that are inside.
Now you do efl_widget_disabled_set(button5, EINA_TRUE);, the state of the window does not change.
Now you do efl_widget_disabled_set(win, EINA_FALSE); now the whole tree is enabled again except button5. Its still disabled since its explicitly disabled :)

This is why this is now an int and not a boolean flag anymore.
(btw. the behaviour above can also be done in legacy, which makes sense to me :))

A int might be a big giant, maybe a short or char is enough ?

@bu5hm4n @YOhoho
Thank you,
and I made D8005 because both of your comments looked correct :)

I cannot find any trace about "moved" event. Somebody knows about this ?

@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 only "create", "release", and "created" event.
That is, "model_connect" needs to be included to another interface (or class).

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.