Looks good to me.

Thank you very much!

sorry for late update,
we are so busy as the issues season comes again...

@ali.alzyod ,
this code is reported in code verifying tool,
and I do not know what exactly you intended here.
is it okay to remove this line? or should it be non-zero checking?

@cedric please re-check this patch with D11227

I think we could add more layout helper method such like
efl_ui_layout_signal_signal_emit.

add I for interface GenericFactoryExtended and GenericFactoryPartExtended.

removing underline in GetPropBind and GetFactoryBind for complying mono naming rule.
virtual public to public virtual.
line indent fix.

this patch will be replaced to D11211

I think we get agreement about this patch, so if I update new layoutFactory depends on this patch, it is ready for accept, am I right @cedric?

update patch with removing layoutFactory, and generic for all.
fill the doc comments but it need to be updated later.

@felipealmeida
please check this and give us your opinion how to go.

fix typo

Do not merge yet as this implement need to be discussed in right way.

I think it would better to have only one way to get the event for user,
so they don't need to care about child or children,
so if it has to be changed,

remove smart check.

update comma

@segfaultxavi,
One question about event stabilizing,
the class of efl_model is since 1.23
but these events beta and being stabilized in 1.24,
so do we have to put the @since tag on the event either?

I'm not sure it can doable in app side level as _elm_widget_item_view_clear is elementary private function and all deletion process in genlist is also internal.
hmm need to think about the way of doing this again as application can intercept the deletion also...

@cedric
I have one question regarding all composite model.

agreed.
now everywhere we can see the unit for model,
and to change this, we should change all of them and I don't think it is doable thing as most of them are already stabilized.

I think it can be out of beta as index_range is already stabilized.

thanks for fast fix :)

@cedric
isn't multi_selectable_index_range also needed to changed uint64 ->unsigned int?

change item->eo_obj to eo_item.

I have a question regarding this clickable part.

no, I don't want to :) I'm just asking any possibility cause I hope it would not.
I think we got an agreement that most of mvvm infrastructure is firmed,
so I want to move forward :)

I'm more prefer to have abstract way to indicate the item as index can be changed by inputs,
but it's time to decide whether we go with int or not...
still int index is widely used for indicate the item in gui frameworks,
I think user fully understand that they need to tracking input changes to get the right item.

are there any chance to change this class name or method?

@by_Ref ?

One big question regarding this header and footer is...
how we support horizontal header/footer.

I'm thinking to adding more item styles,

I like the names.
after few reviewing on the class method, I think those two either can be stabilized :)

issue is resolved.

more right way of reverting it is revert elm/genlist: defer recalc when applying a name filter either

In D10649#199394, @segfaultxavi wrote:

As the documentation I proposed says, when MODE is AUTO, the user cannot know if the scrollbar is currently shown or not, right? This is what efl_ui_scrollbar_visible_get() does.

let's guess user want to make an item with progressbar in the center.
or some complicated layout like 3 line text and 3 different check and icon and button.
there are tons of different demands of making their list by their own gui,
we cannot support all of them.

it only hold one swallow part which have the same size of item.
It is just single item container which make user customize their own item without using edc,
so yes, it could be default item if user make an horizontal box and pack the two icon and label. that is the example case I guess.
the idea is,
user may decide the size of item(or their content) by set the min size themselves,
and decorating item as it's own demands.

so the conclusion is we maintain current classes as what they are?
we spend too much time to find out best figure for this,
so I'm okay with current way as it is the conclusion of long discussion.

@segfaultxavi
isn't it too overlapped with bar_mode set?
we already have EFL_UI_SCROLLBAR_MODE in both axis,
with a AUTO(means if content is bigger than viewport, scrollbar shows, if smaller then viewport, hidden), ON, and OFF.

• Default : I think Default is quite generally used in this case but standard also looks good.
• Placeholder : I like the Decorator (or Decoratable) as a name, though placeholder is more intuitive.
• Context : First of all we need to define what exactly this item will do. if it only works with flip(or slide) the item and give another options, Slidable or Hidden_Option can be used. I prefer to have more confirmed type of item not too general and can be understood in many ways.

so is this some alternative way after removing select_always?
as I see the usage looks quite similar..

I'm not tested every cases,
but it seems works as what we expected.