it is duplicated patch of D9601

I'll abandon my patch :)

1. you mean the index id? I think for the range, integer id would be much easier to understand and use for the user, but mostly user have object handle not the integer id... but they can get the index of item easily. if we do not make our index_get poorly like O(n)... I think using integer id is more intuitive.
2. I think we need to give common experience on that usage, like mobile multi select by click, desktop multi select by ctrl or drag, so it is profile dependencies then widgets.. I vote config.
3. the case of how implement it will be different per widgets I think, like collection widget, they have all the items list, they could manually update the selection on items, but in the view, data should be updated on the model... I don't think we need helper class for this selection. but let's see how many widget want to selection and how many widget have common implements.
4. seems good to me.
5. I think that is select_always. mostly if I clicked selected item, it should be unselected, but in select_always mode, it remained selected state. but in multiselect, selected item should be unselected, so I think select_always is only for single selection..

D9557
seems almost same but I think user can be set a group or klass only as assuming style is default.

I'm not sure @cecric is okay with keeping cache data without model in listview.
also calculating item position in every calls could be inefficient if it calls frequently..

Hi. sorry for late answer.

I was requested this feature from the tizen developers several times but at that time we couldn't have enough time to fix it so reject the request but if we can do this, it will improve scrolling performance very well.
I think it need to be 3 buffer for this, one is in the viewport and others are for the top and bottom....

yes. we can go with current group index.

Seems valid fix to me.

should listen others opinion,
but I like this patch and it is exactly what I expected our selection interface should be.

but the who will be managing the data? view itself? or viewmodel should?
we have statesmodel in the elementary,
I'm not sure we have plan to use them.

@bu5hm4n yeah we don't have code to skipping it yet.

the reason it has sizing eval is there are some demands that skipping sizing eval such as homogeneous size in the list or grid..
if we already know the size, we could skipping restricted size calculation and set the size by it's container.
I didn't write the code for skipping case, and that is why you couldn't understand the existance.

In D8080#173714, @lauromoura wrote:

In D8080#173675, @cedric wrote:

In D8080#173573, @lauromoura wrote:

The idea is to be able to bind properties from the Part to properties of the Model through the Factory, right? Do factories already support binding properties of parts of their item class? (@cedric?)

We haven't moved properties to be Part yet.

Assuming that works, the C# syntax for binding parts properties could be something in the lines of:

var factory = new Efl.Ui.ItemFactory<Efl.Ui.ListDefaultItem>();
factory.TextPart().Bind("somePartProperty", "someModelProperty");

(Note: This requires the parts to be declared in Eo files as we would need to generate extension methods for them to we can extend ItemFactory.)

remove un-wanted fix.

@cedric @felipealmeida @bu5hm4n
as my understand, our efl_view_model or efl_ui_state_model need to take control some ui-related boolean states in the model data.
enable/disable
select/unselect (by interally adding select_model)
visible/hidden

Yeah...that was ugly.
I prefer this collection naming,
but only concern is collectionView is used in other framework as actual collection shelf view.
yet I think it is doable name till we have other good candidate.

Test Note,
as I tested in latest version.

what else do we need for this?
if it is ready for merge, please let us know.

remove efl_ui_layout swallow part fix.
this will be udpated another patch.

fallback the efl_ui_list changes,
clean up efl_ui_item signal emit which is duplicated code.
add 'efl.extra' in layout part list.

I realize that this patch is totally wrong.
we do not need to send any signal to text or icon, cause layout already send visible/hidden signal on the text and content.

currently this is internal infrastructure.

I hope we separate the single select option and select mode,

update patch

well then we could think about another names,
itemBox, itemWidget, itemScroller(?) itemCollection, itemLayout, itemController...
but most of these also have same problem...

I think all three MVVM related ticket on stabilized,
T7578
T7579
T7580
would be better to halt stabilization till the MVVM implementation and mono binding are stable.
any idea?

these selection is more releated with entry and clipbaord cnp feature,
so selection_type doesn't looks general.

I think mvvm is not stableyet and the list_view_item_event need to be changed by fallowing changes.
first of all,
layout need to be changed Efl.Ui.Item.
anyhting else?

oh okay.. to get their parent, make sense.
although mr taehyup working on some abstract c# items which wrapping the efl.ui.item without edje layout... still it seems helpful.
thank you.

In D9201#170977, @cedric wrote:

In D9201#170416, @bu5hm4n wrote:

My proposal to this is:

• Keep the themes for list and grid like they are right now. This is just a general item style, which is unrelated to the widget it is in.
• Add an API to the default item, which lets you set the prefered item style, a item style "aXa" would result in a theme group name "efl/aXa_item", The parts the layout accepts is standardtized, so are the signals. When the API is changed, the theme is set again to the layout, resetting the elements.
• When you add the item to the item_container, the item gets passed to the Position_Manager (that is the actual name of what you call layouter) who can set the item style it wants to have, other widgets can also just do that.

I will add to this:

• CollectionView (the V of MVVM) will also be able to use Position_Manager and we won't need to code a grid and a list, just reuse that infrastructure.
• We will introduce helper class that already do set the Position_Manager to List or Grid for ListView, GridView, ListContainer and GridContainer (or whatever name we choose for them).
  
  It will be possible for anyone to implement their own Position_Manager, like for the list that Samsung use in Watch, or a cover flow one, or whatever.

if it only need to be called by the container... is there any reason that it need to be eo API?
hmm... I think the patch is aceeptable but don't know it need to be a public.

hmm so this is the way you want to say the container widget before it packed... interesting..
so what if user forcely change the container after packed?
shouldn't we call the unpack or something?

the patch looks correct fix.

DO NOT MERGE
to stabilize the item and mvvm feature,
let's keep this patch in do not merge stand
and reactivate it later.

@bu5hm4n is this concept can effect your container idea?

oh, okay. I'll revise the patch.

@zmike, yes,
and in the case item-emitted callback,
factory provide the abstract way of adding event on the item in mvvm case,
we don't have any prototype for this,
so I might be earlier to be stabilized...

This class is renamed as
Efl.Ui.Property_Bind
also it related with
Efl.Ui.Factory_Bind
I think this class is ready, but just need to be confirmed @cedric and @felipealmeida as it is good enough to using item_factory in mono binding.

I also agreed @cedric.
once we were talking about name change to "model_client" but view is more generic and acceptable.

Oh....... sorry I was totally misunderstood about your comment..
so want to merge the list and grid in one item_container,
so you want to using "theme" namespace instead of list or grid class.
sorry I skimmed through the comment.
we wasted a day.. my apologize.

hmm... I got your point
but as I see... that is too tricky.
as I mentioned, list can use efl_ui_item or efl_ui_list_item,
and it has different namespaces in the theme,
so container should take care of this different namespaces in theme_set.

currently it is private data structure, and I think we might not need this structure anymore with the size model.

for the notice,
this patch is the first try of merge this two different style classes,
and not the complete one.
after this patch, I'll keep update the patch with better optimizations.

fix typos.

As we discussed in voice call meeting,
Event abstraction on item can be the additional role of factory.
here my question is, if factory can abstract the event callback add,
what object should be passed as the result of this event? item object or widget object with index as event info?

in MVVM case, as cedric pointed,
child of Efl.Model will be the invariable value for specific item,
but in view object, numeric index can be accessible.

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?