looks valid patch for me.

rebasing and update while to for statement.

this bug is detected by our coverity and I think this is right fix.
also there are some warns about memory leak of cbuf, but it looks reallocation of tbuf, so it looks safe on my view, but I hope you double check it.

but as you see the code,
in realize case,
it get the return from elm_widget_item_tooltip_window_mode_set which redirect elm_object_tooltip_window_mode_set,
and in elm_tooltip_window_mode_set,
it returns input disable.

typo

It works very well. thank you so much :)

oh its wrong patch.

I tested and it fix the problem well :) thank you.

fix the dependency file including bugs

In D7857#139559, @bu5hm4n wrote:

It appears that we are recursivly skipping interfaces, but not on the direct implementer. I will look later next week into it.

remove wrong file includes

• eo: Fix efl_isa for class checking of recursively inherited types

Do you have a old efl_ui_layout.eo.c arround somewhere in your tree ?

I think I resolve the problem by recursive calls of efl_isa for mro

The issue case is easily found in example of efl_ui_list_view_example_1.c

In D7857#139524, @bu5hm4n wrote:

Mhmmm MRO should contain all recursive classes.

looks something wrong in the patch.

fix unnecessary changes

fix meson build and warnings

fix po file includes

fix meson build error

dependency update

depends on D7529
renew the patch with inherit layout factory.

renew the patches.
adding new two interfaces,

Keep in mind that all the above are for Eina and Legacy methods, apparently we haven't introduced any insertion method in the Unified API yet, so this will be the first one and we can decide to change the rules :)

ALSO, don't forget to document how to insert easily, when you don't care about the insertion point. I am assuming you will use relative_to == NULL? The current diff does not specify this.

fix few typo which was generated by conflict resolving

rebasing patch and resolve conflict

Looks good to me.

one better idea that @smohanty suggested,

In D7682#138545, @segfaultxavi wrote:

Thanks a lot for your patience, @SanghyeonLee, and for a very clear explanation. With pictures!
Unfortunately, I do not think we can add pictures to the EO docs yet :)

I understand now that both partition_rows and partition_columns are needed.
My only comment now is that maybe row_count could be renamed total_row_count to make it clear that it includes the rows outside the viewport. What do you think?

looks good to me.

yeah naming is really difficult thing always :p
though I like the Swallow_Item idea,
but if you two are voted Placeholder, so I'll go with it.

@cedric, I don't remember exactly which case have some conflict problem regarding this,
so could you give some example to explain the problem?
this would very helpful to understand problem for @woohyun and @Jaehyun_Cho

shouldn't we abandon or resolve this item?

we can hiding them in private class, but for making list and grid, tree view with generic interfaces,
making it as common class or interface will be much easier for implement them.
also about layouter,
I think currently it need to be private cause we do not decide which structure we will exposed for model handing on the view,
but the final goal in my thought, it would be better to publish them and user can customize this layouter as what they really wanted.

In D7474#137711, @cedric wrote:

In D7474#137368, @segfaultxavi wrote:

OK, thanks @cedric for the explanation.

These are my two cents:

• Regarding Empty_Item or Content_Item:
  • I do not like Empty because it looks like it has nothing inside.
  • I do not like Content because all other items have content too, this is not the only one.
  • How about Custom_Item, Customizable_Item or Placeholder_Item?

I like both Cutomizable_Item and Placeholder_Item with a slight preference for Placeholder_Item.

In D7474#137211, @cedric wrote:

In D7474#136789, @SanghyeonLee wrote:

about the grid... content_item can be useful, but default item, they might need different visualization in grid actaully.
the idea you told me can reduce the useless repeatation of item classes, so in some ways, I agreed.
we can go the common item styles,
Efl.Ui.Default_Item
Efl.Ui.Content_Item
Efl.Ui.Title_Item
(note: we cannot go with "View" term cause it still used in Efl.Ui.List and Efl.Ui.Grid)
but I think internally they might checking who is my parent class and find different edje styles based on parent class, like,
efl/list_item:default
efl/grid_item:default
efl/tree_item:default
in the edc styles.

I very much like the idea of relying on the parent class at creation time to define the edc style. Still it might be tricky to manage to do that as the style is provided by the model and the model doesn't see the parent class. We could have a dedicated model for each type of View that generate the proper style information. If you have an idea on how to implement this, I will love it as I really think having a limited amount of item class would be best.

after this dicussion,
i'll abandon this patch and recreate / split new patches with

Could you use git phab in the future? It is easier to work on bigger series of patch with it.

rename empty_item to content_item(is this name okay?)

This is one of the item that really look like it could be generic for all view. What about efl.ui.view.content_item? For @segfaultxavi, the style of this item is completely neutral, no decoration and can only contain one object inside it.

In D7682#137381, @segfaultxavi wrote:

Thanks @SanghyeonLee ! Now I have it much more clear.
I now also understand that the direction in which the grid grows is controlled by Efl.Ui.Direction, and not by partition_columns or partition_rows. In fact, once you have set the direction, only one partition is needed, and the other is useless, correct?
Then, why don't we just use one partition value?

• If the direction is horizontal, partition controls the number of rows and matches row_count (except for the rounding).
• If the direction is vertical, partition controls the number of columns and matches column_count (except for the rounding). If you agree with this, make the changes in the code and I will then propose the docs.

looks good to me.

Looks good to me.

please check the test again.
base_ints breaks in make check.

looks good to me.

check tested.
looks good to me.

looks good.
some efl_ui related test need to be rearranged now.

looks good to me.

looks good to me.

I think code looks good and build/check works well.
only the meson build may not proper to fix in this commit.

looks good to me.

It looks good to me. build, check all passed.
but one thing I have a question...
we remove boolean_child and select_child,
don't we need to remove container_item also?

In D7812#138406, @segfaultxavi wrote:

I know this is already committed but, in the future, please do not commit commented code.

rebase patch

update patch. fix build errors

In D7533#137469, @lauromoura wrote:

In D7533#137460, @SanghyeonLee wrote:

Current diff may not buildable yet but i updated for the backup of my task.

Maybe add the "DO NOT MERGE" tag while it is not finished?

Current diff may not buildable yet but i updated for the backup of my task.

rebasing patch with depending on all cedric's patch on top of
D7705

It looks dependencies broken in arc patch, so it tried to cherry-pick D7649 which was already merged.
it may need to abandon some related patches I guess though still we can stack the patches with skipping dependencies.

I think this patch need to be abandoned as it already merged in D7654

I think this patch need to be abandoned as it already merged in D7654

I think this patch need to be abandoned as it already merged in D7654

In D7654#137294, @segfaultxavi wrote:

We are now stepping over each other's diffs so I'll propose doc changes in a later commit :)

One last comment regarding capitalization of property names. You now have different notations: "Child.Index" but "child.selected", "self.selected"...
To aid you in the decision, part names and event names are lower case :D

In D7682#136995, @segfaultxavi wrote:

I have a few comments:

• partition seems a bit unclear to me, I would call it visible_rows and visible_columns.

one doubt about this...........
shouldn't we hide the extern struct Efl.Ui.Item_View_Seg_Array_Node also in efl_ui_list_view_types.eot?

hmm but still there are some doubt about idea...
what if we need different efl_part in different parent classes?
I think we still need list_item and grid_item for these cases,
and I'm agreed with combined item class for what we can provide.
same style name, same part properties..

about the grid... content_item can be useful, but default item, they might need different visualization in grid actaully.
the idea you told me can reduce the useless repeatation of item classes, so in some ways, I agreed.
we can go the common item styles,
Efl.Ui.Default_Item
Efl.Ui.Content_Item
Efl.Ui.Title_Item
but I think internally they might checking who is my parent class and find different edje styles based on parent class, like,
efl/list_item:default
efl/grid_item:default
efl/tree_item:default
in the edc styles.

yes I think it might need @segfaultxavi 's review about the documents.