I've tested few cases that I worried about,
but looks okay with it.
thanks for the work :)

fix the example crash on text_set and icon content_set.

I think this patch is not ready to land yet,
as it get crashed on efl_ui_list_example_1.c.
please do not merge yet.

I change the place_holder to placeholder so is there no problem in the name,
I think it is ready to land.

remove unnecessary spaces.

remove diff of depends patch

fix place_holder to placeholder

yeah I was consider it as a single noun, "placeholder"... it is my mistake. I'll fix it :)

update example code.

update missing theme part name changes.

update patch with change part names,
Text_Default -> Text
Content_Icon -> Icon
Content_End -> Extra
Content_Placeholder -> Content.

@segfaultxavi @q66 thank you! I'll update the patch as commented way asap.

In D8582#165281, @segfaultxavi wrote:

Currently the bindings add a Part suffix: a part named color generates a C# property named ColorPart.
This should only produce a conflict if you had a property named color_part, which would be very strange.
The same problem exists if you have a property named changed_evt for example...

I think the only way to be sure is building the bindings during tests.

In D8582#165222, @segfaultxavi wrote:

In D8582#164893, @SanghyeonLee wrote:

the conflict is detected when validate the part name of class property hash.
I think this check is still valid thing, somehow, as property could use "part_" prefix though we have to avoid these prefix.
so instead of adding prefix in c# binding only,
what about adding prefix in eolian part->base.name directly, when it store the stringshare?

In C there is no clash, because properties and parts use completely separate APIs (class_name_property_get() and efl_part()).
In C# though, properties and parts can both be accessed through standard C# properties, and therefore there is collision (class.Property and class.Part).

For this reason, I think the collision should be fixed by the binding that cause them. Otherwise, we introduce artificial restrictions to the other languages.

Did I understand your concerns correctly?

In D8784#165276, @cedric wrote:

I do still think View is a conflictual key word that is expected to mean something like View in MVC, MVVM and friends in any other language/framework.

hmm I agreed basic idea of this patch....
one my concern is when item size need to be updated by text / content changes...
i'll do few test with this patch and review it again.

hmmm I have one suggestion,

In D8582#163424, @segfaultxavi wrote:

The C# bindings now automatically add the Part suffix, so we do not need to use any prefix or suffix. label, icon and extra should be good enough names for parts now.

The problem is that Eolian is still enforcing that part names do not clash with property names. Can this restriction be removed, @q66?

Also, be careful, there's still commented-out code in efl_ui_grid_default_item.c

can you update status of this diff?

is it okay we go Part_XXX ?

the idea looks good but the document need to be checked by @segfaultxavi..
and I think property_string_add/del is better to avoid some confusion of text_set/get

@cedric @segfaultxavi thanks for nice idea.
@lauromoura thanks for testing.

yeah as I told, this is just readability and preference problem so author think this is right, let's push it.

okay then, I think its ready to accept.

I think code looks fine, but I found few preference coding styles,
I don't have strong opinion so if you thing current way is good then I'll be accept the patch.

ping?
any opinion about Efl.Part? or naming?

code and idea looks good to me, but it is quite hugh code so it would be better to have some test or examples.
do have any plan for this?

test passed with dependencies skipped patch.

okay let me try the build and other test. give me minutes.

opps sorry I didn't see that.
should we wait the opinion of @segfaultxavi ?

I like the idea of this patch,
but could be better to give simple explains about custom-mapping as comment for the test writers.

thank you.

I got the point after reading the efl pack at document....
though it sound like....VERY WEIRD to me..
but it's @jpeg 's design.... and we should have to fallow the definition.
thanks for updating this feature.

code could be duplicated because they are almost same item-based widget, except the layouting... but I don't know what you mean second layout function.
our plan is support list and grid layout with pack-interface on simple case and MVVM interface on more complex or hugh data handling.
efl_ui_list was written before efl_ui_grid, and I planed to use efl.ui.box internally for simple implements, and it works as well for list layout, but
about grid requirement comes, I couldn't use box anymore so I have to make whole pack interface internally.

ping?

stringshare_add also check hash and if it already hashed, not generated new stringshare.
this looks valid fix to me.

looks good to me.

looks valid fix. though it may user fault, I agree we should give error message and exception handling.

if user input is wrong... I think we should fail the request not rollover the index...

looks valid fix. thanks.

Looks valid fix. thanks for fixing it.

looks good and clean to me.

I'm little bit worry about 32 bit system needs in the future on tizen side,
but currently it seems we all uisng 64 bit system and it won't be a problem.
I've recently faced some signed-unsigned default datatype issue on char,
so using strict datatype could be nicer to avoid such problem.
lets to discuss again on this matter after all infrastructure is ready :)

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