@felipealmeida so you want the original way that we dicussed before in Aug? I think you agreed with @cedric 's opinion about dropping that..
I'm not sure i totally understand your opinion so it would be better to explain this with simple pseudo-code or c# examples.

@felipealmeida yes we dropped it. the only one reason I brought it again is our basic agreement of using create event with Efl.Part is now being dropped again and I need any-idea to support item creation in factory with efl.part.
@cedric why can't we just say in the documentation that after setting the class on a generic factory, it will follow that class binding capability I'm not sure I understand correctly,
this line means, we don't expose the efl.part and user set it manually like this,

well we can lock the object or only accept the setting in "Set" function calls.
Similar Concept is used in QT with name of ItemDeligate.

I... also not sure cause create() is asyncronous and this event should be emitted when create() is ready but it looks quite weird that factory event including some model-based information. if it's view side, it make sense that item holding an model information so may be it need to be emitted by view.

Oh... I missed this task, sorry for late answer.

To support this, we need new factory which make in List or Grid Item not Layout, which may allow to set size manually without layout_sizing_eval.
factory could support homogeneous_size_set/get().

yeah agreed. and we could apply new feature of extendable scroller... like, we read only small range of model and create scroller with this items,
when it reached end of the scroller, we request another bunch of items, like, extending scroller as it's edge.
android and ios and some web site like facebook or twitter already using this kind of scroller concept widely, so we could support this in MVVM level. what do you think about this?

I think this task could be just moved our View Model Helper task. as you mentioned selection as a helper of ViewModel, enable disable is just one kind of pre-defined viewmodel property with some helpers.
for examples if widget is disabled, whole sub item need to be disabled. when the widget turns enabled, all sub item need to be enabled. and also when all sub item is disabled, widget could be disabled..
the helper API could be support this kind of simple works in my thought.

well I was think to make it as an proxy model which can user "sort" or "filter" their original model.

about D7332,
mostly view will request some bunch of items in one request,
so it would be much nice to get series of them in single event or future, but I don't know how to do this.
maybe your current patch could be thing that we can do best.

But as you mentioned, adding styles in eo is not high priority, then we must find some other way to using Item class easily with Efl.Part infomation.
also we are not a big fan of using styles property on this case,

Hmm
on the create(),
if we can support some kind of internal item caching by protected method, this will be very helpful for them. I think create() is too big function that might user need some helper APIs that can replace common actions in create() like send signals, pop_cache, evaluate size~.

I'm sorry that I didn't see the details of samples,
but in that case, when create() called by view to list factory, it calls create() to their sub factories?
hmm... could be.
so the liFactory in your sample looks like.. kind of composition factory..
that is what I want to speak.

we can support changed event by interface like, Efl.Ui.Observable

factory_link? or factory_property_link?
I'm also find with that.

looks valid usage for me.

is it event or function?
fac.create() is function which will create an class instance directly,
Create_Event will be a event which will be called when factory create an class instace.
so the T7473 and this Task talking about same thing or different one?
I little bit confusing here :)

so what kind of event information need to be given in this event you think?
I think below three is required..

rebasing

Looks good to me.

So the problem is... actually we consider the option you suggested before,
but we drop it because,

rebasing commit

remove view_grid in the theme.

h://git.enlightenment.org/core/efl

update meson build

rebasing with layout renaming and add meson build

@felipealmeida
though it is possible, it will need more time to implement this, so not a proper target for now. it should be later works i guess.
and also that would be more related with "style"s not "part" properties as I remembered, like user can easily find there styles by looking at pre-built theme classes such as,
Efl.Styles.List.Default;
Efl.Styles.ListItem.Full;

TBH, I think it doesn't really big different to user side excepts they have to put some dot between the namespaces.
most IDE, if you find Efl.Ui.List, it will show every List* classes regardless of namespaces.
so I'm not strong opinion here, just the only thing I hate is... as @segfaultxavi mentioned, we need to put "Object" or "Widget" for widget class name at the end if we go with namespaces.

@bu5hm4n @segfaultxavi ,
so you meant layout will be an namespace so every layout based widget will belong to this layout namespace?
like,

rebasing

Yes..actually deadline is now being more urgent, cause there are some plans to using this feature soon.
at least basic factory need to be ready till end of this month and multistyle factory and the other stuff also need to be ready before the end of the year.
I, also have to finish gridview and grid factory beyond this work,
and some Tizen specific class and visual effect need t be ready in deadline so that should be my work also.

2. Okay.
3. you meant item factory or image factory? or both of them? If in both case, I think we can remove setModel from factory fully.
4. yes. so the our idea is basic one and.. if some other requirements comes, let's expand it more.
5. Okay. not bad actually.

I think its now ready to land.
so remove do not merge tags, and wait for review.

fix conflicts and rebasing commits

We are discussing about new item based on Efl.Ui.List_Item which will have some Efl.Part informations.
I thought we've already had some agreements of using Efl.Part instead of string and connect(),
so I wonder why this subject is repeated again.

this task was closed by D7234.

Update missing files.

hmm... that was previous way and I'm talking about the way of using Efl.Part in Efl.Ui.List_Item with factory create().
this was discussed with @felipealmeida in the last meeting at August.... I'm worried about this conversation was not progressed or shared with you....

rebasing commit

Here I brought you some sample code of applying multi style factory in the view.

One more thing, this task also include the way to get Efl.Class by some predefined class values as like liFac.ClassAdd(Efl.Ui.ListDefaultItem.GetClass(), "item_class", "default");
To make this task possible, it should be pre-implemented.

I like this idea that makes more simple on the user side code. how much time do you think to make this features and apply the models?

yes as far as I know. and only we need to verifying them. I think we could expose some API for user-convenience.

so you meant this propertyGet returns observable value and label will detect the value changes and set the text internally?

can you add this idea to the pseudo code or samples of T7441?

I have to see the sample code about what you talk but, yes, I agree that we need some other interface for getting property values rather than events.

so the better solution for optimizing is applying homogeous size of items for most useless size calculations.
but though we need to calculate every items in the list,
we could give some trick for them to optimize calculations.

sure I agreed. that is why I assign this task more lower priority than selections.

I can't understand the issue cases. which case may not guarantee the ordering?
I think if we cannot guarantee the order that we requested,
we should let the user know the failure of inserting by returning errors and do nothing further.

Looks good to me. @YOhoho if you have other opinion please let us know.

Update grid widget and test / examples

• update wrong grid item position calculation
• update grid test with scrolls
• update grid example to test vertical case with text

update test cases and themes.

update efl_ui_grid pack test in the elm_suite and add grid.edc

fix typo

fix typo

rebasing patch

In D6985#121040, @bu5hm4n wrote:

There is the project DO NOT MERGE :)

THIS COMMIT IS ON DEVELOPING PLEASE WAIT UNTIL IT IS READY TO REVIEW

looks good to me.
it would be better to keep the original author to tracing history but it too obvious fault and we can trace the history under lines.