Remove resize object again. :(

optimize chain_calc

Remove resize object. it is unnecessary.

Nice docs! I am approving, but only documentation-wise :)

Add documentations.

1. rebase
2. refactoring
3. add more tests
4. implement chain relation (efl_ui_relative_layout_example_02)

Oh this seems like it could relate to some of the performance improvements speculated on by @raster in D7471. I wonder how this might impact any potential gains which blist could have provided?

This is really interesting. I am wondering what the memory impact will really be. We moved clipper into the COW part of Evas_Object as it wasn't used that much. So my guess is that it shouldn't impact memory consumption that much. Still I would be interested to get a memory profile of elementary_test, enlightenment and terminology and see what it says.

Ticket D7471 proposes a new list technique with some compelling cache efficiency and memory usage characteristics. However, one of the things it's not great at is removes, as it has no equivalent to eina_list_remove_list, which is an O(1) list removal.

Rebase and remove relation_dir_to_set, relation_dir_relative_set apis.

@cedric
Agreed.

relation_left_set(Eo *obj, Eo *child, Eo *target, double relative);

Would cover all cases passing NULL.

In D7524#132938, @YOhoho wrote:

1. add elementary_test example.
2. rename to left, right, top, bottom.
3. remove register api. (when a child have relation, it is registered)
   
   I want overload relation_#direction# apis. for example,
4. relation_left_set(Eo *obj, Eo *child, Eo *target) to set only to.
5. relation_left_set(Eo *obj, Eo *child, double relative) to set only relative.
6. relation_left_set(Eo *obj, Eo *child, Eo *target, double relative) to set both to and relative.
   
   However, EO doesn't support method overloading. so there are xxx_to, xxx_relative apis.

update a meson builf file

1. add elementary_test example.
2. rename to left, right, top, bottom.
3. remove register api. (when a child have relation, it is registered)

implement margin

OK, I'll wait for the new docs before reviewing. I am rejecting this version so we do not forget and this patch gets merged without documentation :)

In D7524#132661, @cedric wrote:

I am not to sure of the name of this new class as it doesn't express in the name the fact that it is a container. Also, and it is something that I am sure @segfaultxavi will point out, it is lacking a lot of documentation :-)

Rename to Efl.Ui.Relative_Layout

1. Rename Efl_Ui_Relative_Param -> Efl_Ui_Relative_Relation and integrate rel1 and rel2.
2. (API) Rename rel1 -> left, rel2 -> right for intuitive names.
3. Add Get method for properies.
4. Update Class Diagram (check above comment)

I am not to sure of the name of this new class as it doesn't express in the name the fact that it is a container. Also, and it is something that I am sure @segfaultxavi will point out, it is lacking a lot of documentation :-)

Could you move the definition of struct Efl.Ui.Relative_Params to efl_ui_relative.eo file?

Interesting :D

Update generating documentation for properties.

On a second thought... properties should have documentation :)

Rebase.

In D7394#129152, @lauromoura wrote:

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.

In D7394#129135, @segfaultxavi wrote:

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.

6ec6d93535ebda03e1a4fac28b13d81b9ec79ee7 fixed make check for me.

Well, just renaming the interfaces wouldn't be enough, as implementing classes like Efl.Ui.Text would still conflict when they implement the interface property.

Updated version supporting interface properties.

fix conflicts and rebasing commits

rebasing commit

I guess problem is that scroller have focusable dummy element when it doesn't have focusable content. but it is not included in pd->iterator_list in _efl_ui_focus_manager_root_focus_efl_ui_focus_manager_border_elements_get. so, scroller can't find focusable element.

I meant focus move policy when scroller have focusable content.
The interaction problem between scroller and other widget is focus manager side issue.

Yes - you said that @eagleeye will handle it and assigned it to him... https://phab.enlightenment.org/D6587#118371

@bu5hm4n
ping, scroller which have no content still can't get focus

Update grid widget and test / examples

• update wrong grid item position calculation
• update grid test with scrolls
• update grid example to test vertical case with text

update test cases and themes.