code looks good, only few question about uint64 and exclusive term.

code looks fine but as I remembered there are some question about uint64... do we really need to use uint64 not general integer?

looks good to me,
@segfaultxavi do you have other opinion?

In D8582#156556, @segfaultxavi wrote:

I agree with the intention of this commit, which is putting together in the same class repeated parts from different classes.
However, I think we can go even further. Looking at the patch, it looks like the parts for Efl.Ui.List_Default_Item and Efl.Ui.Grid_Default_Item are identical. Could these parts be moved to Efl.Ui.Item, for example?

so do you think we need to restrict factory input as Efl.Ui.Item_Factory only? or just change the property name as factory not item_factory?
I like the first idea, cause every code of list and grid will guess the object created from factory is Efl.Ui.Item not other class,
so if it comes something else, it is really hard to handle exceptions.

this patch is abandoned after create new patch D8582.
rerfactoring on item default and renaming empty item will be continously updated.

I was told about D8568

fix typo and examples

remove unnecessary po changes.

sorry I was design it and I have a plan to update this to using Efl.Ui.Item_Part_Icon and End not generating same part repeatly, but in here I was thinking that doc need to be updated,

can you update depended patch?

is this patch ready to go?
please comment more detail about this patch in commit-message,
and rebase on latest master.

sorry for late actions.

sorry for late review.
on the purpose of removing unnecessary order setup, this looks valid patch.

@zmike, we have some testsuite for this elm_object_orientation_mode_disabled_set and it fails after your refactoring of this method.
the code looks never change once it disabled in non-layout case, I think it need to be fixed like this.

this is not a final version, only buildable one. need to figure it out which one we need and not in both of grid view and list view

ping?

remove unwanted files

it looks zmike disagreed and I respect orignal authors opinion.

I really not sure but if we goes the event name as properties,changed, it sound more natural to change the other event name as properties,bound?
I mostly prefer the singular name on the APIs and Events, but unity is also very important thing in my thought.
is this property bound only come with single property not a list?
then it sound correct.
I'll change my review status after you pointing what is right.

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 want.

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.