Huh ? scroll to the function _evas_box_remove_all, you will see that this function would also just fall for recursive uses, like any other while loop that walks the children somewhere in efl.

make xavi happy

nooooooohohohoho.

If this here would end up in recursion, then you also will end up in a recursion in evas and or elm. as we *always* use this sort of thing to free items etc...
Additionally, if you end up feeding objects into the box everytime you remove one, you have a endless recursion, i think it does *not* make any sense at all, protecting against that case.
And last but not least: In my opinion the code with l asks for trouble, as you kind of removed all children from the widget with the assigning of NULL *or* you have for some times invalid memory in the private data. So i would definitely keep this here, instead of keeping l.

make layout orientation a constructor property

Thanks.

I am okay with the API side, only one thing impacts the API right now:

• _efl_ui_textbox_efl_layout_signal_signal_callback_add still has a problem, the object of the function callback will be wrong

That sounds indeed like a very good idea, and a lot of deduplication.

...

Why am i unable to accept this ?

Thank you

Mhm, i do not have a real impact on the order of libs there ... that is the result of some internal windows libs.

So starting the textbox widget and rightclicking on the widget will bring up a popup with a list list and a few items (one of them has the label "cut"). The cut item has a CLICKED handler that will delete the entire popup.

That's cool :)

Cool, thank you.

Something else discovered due to reviewing D11107. _part_is_efl_ui_textbox_part returns valid parts for each and every part name. However, _efl_ui_textbox_text_set and _efl_ui_textbox_text_get do only work for "efl.text_guide" or "efl.text". I think we should change _part_is_efl_ui_textbox_part that it only works for "efl.text_guide" and "efl.text", for the rest EINA_FALSE should be returned.

Well, you can see if the list of failed examples gets bigger or smaller ... :)

yeah, probably true.

Have you moved it *after* the super call to theme_apply?

Thank you

In T8522#149647, @ali.alzyod wrote:

what is text_table, and why is it used ?

it is a container for guided text and internal interactive text

Yeah, good catch.

Does what it should do

When those changes are applied, the theme will be applied automatically during construction.

@segfaultxavi Naaaaaaaame discussion, should be the part Efl.Ui.Text_Part be renamed to Efl.Ui.Textbox_Part ?

Mhm - is there a reason the part class is not called Text *box* _Part ?

I think we can go ahead and land it the way it is, the fix for the error will be outside this here i guess.

Yeah i think keeping it is better. The API does not look wrong, i would implement it exactly the way it is now when ding the double progressbar. Additionally, removing it, means we have to refactor quite a lot of code, which will be simply duplicated by the time we introduce the double progressbar :)

But the rest looks good.

But then better create some placeholder API that just does that (maybe not on efl.ui.textbox). I really have a bad feeling just removing a feature, better stick it in a other place where we can refactor it later on.

I am not sure if the backwall should emit clicked when rightclicked, it normally is just meant to react on left click.

I agree, lets keep these @beta.

I am also wondering of we can just reuse Efl.Ui.Factory, where the model has a single key...

@cedric there was some plan for a range because of MVVM, this looks simular, does that match ?

Just from the top of my head:

• Right now there is this short version of "Inheritance" that starts with the parent class. I think it would be nice to have there as well the list of interfaces and mixins that are directly inherited, just with a link so you can click on it.
• Maybe we can join the Inherited section with the event section, it feels akward to me to have them doubled.
• The Members are kind of very "short" if this list gets shorter due to bullet point 2, we could make something that is a little bit more "verbose" telling what the members are etc.
• The Titles in the property view could get links to jump back to the widget they are on.
• The idea from k-s http://i.imgur.com/EINws0S.png to have something like "C usage" also looks very very nice, maybe something to consider ?
• I get the navigation bar on every site, is it possibleto turn it off, its a little bit out of place here.
• And a bug, taking https://www.enlightenment.org/develop/api/efl/ui/collection and clicking on Efl.Ui.Multi_Selectable.select_mode will not redirect you to a valid page.

Cool - yeah you catched everything :)

Can you now get a backtrace ? One thing is the crash with all details, but at a minimum thing the symbol names would be very good.

This is still failing on travis in a Segfault that i cannot reproduce here locally.

more work on this

Mhm, whats our default policy for that ? I think normally our part_get methods do silently return ...

I am not talking out of fun about line 170. This is pretty much related to this patch, as this makes this test case buggy.
For future patches: GOLEN RULE: do not just add test code to random tests. add new tests. Otherwise we are left with un-debuggable test code, and that is something no one really wants to have.

That's a good start, a few things should be fixed however.

Oh sorry - i somehow missed your reply.

Does not apply

Wait. This test here is buggy for me. line 170 in efl_ui_test_text.c feeds a down key that is not removed.

Thank you :)

In D10968#209136, @ali.alzyod wrote:

In D10968#209059, @bu5hm4n wrote:

One thing is the rebase, the other thing are these freeze and thaws arround the copy. You say they are not needed, but they are still there, so they are planned to be removed ?

As you know there are no copy method in cursor, so we are setting position and we need to freeze the events

@woohyun shouldn't we split this somehow between the unified API and the legacy API ? so the legacy API only works with the attributes equal to the function name, and the same for the unified API ?

fix checks

forgotten changes

forgotten changes

update

more changes

One thing is the rebase, the other thing are these freeze and thaws arround the copy. You say they are not needed, but they are still there, so they are planned to be removed ?

Note, you can run *all* examples after a refactor with ./examples_checks.py in the root directory.

I might be a bit stuborn on this. But isn't array just the same problem as list ? Why not just entering a iterator ?

Mhm the only user of that was clouseau ... But that one does not even compile after renames and eolian changes, what should we do ?

Please rebase this patch on latest master

To be honest, i would either like to see something replacing this feature. But never just removing it ... The listing of Apps that use this stuff is showing quite a bit that we have a rather big community interest for this.

Apply planned changes.

I am still missing a answer to the question why things here have been freezed ?