Page MenuHomePhabricator

elm: genlist counter-proposal for interface
AbandonedPublic

Authored by zmike on May 17 2016, 2:54 PM.

Details

Summary

counter-proposal for genlist

Diff Detail

Repository
rEFL core/efl
Branch
arcpatch-D3932
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 1911
Build 1976: arc lint + arc unit
felipealmeida retitled this revision from to elm: genlist counter-proposal for interface.
felipealmeida updated this object.
felipealmeida edited the test plan for this revision. (Show Details)

Example re-written with new proposal

smohanty edited edge metadata.May 18 2016, 12:02 AM

Hi Filepe,
I see how realize and styling event does the delegate job.

I have few question in the styling and realize event.
Styling :

  1. in Efl_Ui_List_Item_Styling_Event i din't find any model index other than model pointer. So whats the way to find out that , or user has to check the data to see if he has to use different styling.

Realize:

  1. With the Ui_factory for content creation , reuse of content object is still with the listview ?
  1. elm_layout_model_set(e->layout, e->child); in realize callback why user has to call this api ?, as listview has information about both layout and model.
cedric edited edge metadata.May 18 2016, 12:40 AM

Hi Filepe,
I see how realize and styling event does the delegate job.

I have few question in the styling and realize event.
Styling :

  1. in Efl_Ui_List_Item_Styling_Event i din't find any model index other than model pointer. So whats the way to find out that , or user has to check the data to see if he has to use different styling.

Ideally the user should only check the model type to return the style. That being said, it wouldn't cover all possible use case. Question is, is that going to be enough, or do we need more ?

Realize:

  1. With the Ui_factory for content creation , reuse of content object is still with the listview ?

Yes, the listview should be able to check if it does have an object somewhere that match that same style. If it does, it can directly reuse it. We should introduce a reset function on an interface somewhere to make that it work in all case I think.

  1. elm_layout_model_set(e->layout, e->child); in realize callback why user has to call this api ?, as listview has information about both layout and model.

Make sense indeed. Good catch.

felipealmeida edited edge metadata.

Moved efl model things around a bit and added Model Selectable

Other example with some modifications with subhransu's points and with the addition of the eo_replace feature

SanghyeonLee edited edge metadata.May 18 2016, 7:49 PM

Thank felipe for fast feedback, now it goes more make sence.
We got few questions again.

  1. now you create Selectable Model, and it looks like creating selectable property itself(if wrong, please tell me) so what about enable/disable? is it should model data also?
  1. efl_model_connect, efl_model_factory_connect name looks very confusing.

they don't have any model parameter but using model in class name so looks like model should used in the parameter.
what about efl_ui_property_connect or binding then using model?

  1. now style_get are passing index as a parameter, don't you think realized_event also need index data?

for diffrent style as index?

  1. for my understanding, style_get could support the default style set if user didn't replace orignal eo property. is it right?

another question,
now we create one factory, and create content object by this factory,
but sometimes we need callback on this content object.
e.g. button, checkbox...

now there are only one factory about image, but if we support others such as button or checkbox or radio
how we could add callbacks on each items?
how user konw that this callback is came from which item's index?

factory is really good idea and I like it but we should consider this matter for now.
have you any idea on this?

Thank felipe for fast feedback, now it goes more make sence.
We got few questions again.

  1. now you create Selectable Model, and it looks like creating selectable property itself(if wrong, please tell me) so what about enable/disable? is it should model data also?

Yes and no :-) The idea is that sometimes you may want to display the same model accross different genlist. There was no way to synchronize the selection among them. The idea with the selectable model is that if you do pass the selectable model, every genlist will use it for the source of information to know what is selected. Meaning that if you are using a selectable model, if you select in one genlist, it will happear selected in all other genlist.

If you don't use a selectable model, the selection become a property of the genlist and not anymore of the model.

Btw, we need a selection interface that we can then add to both genlist and selectable model. This would be used to manually select a range or retrieve the current list of selected range.

  1. efl_model_connect, efl_model_factory_connect name looks very confusing. they don't have any model parameter but using model in class name so looks like model should used in the parameter. what about efl_ui_property_connect or binding then using model?

You are indeed correct. It should not be in the Efl.Model interface. Most likely part of Efl.Ui.Controller, no ? If so the name should be : efl_ui_controller_connect and efl_ui_controller_factory_connect.

  1. now style_get are passing index as a parameter, don't you think realized_event also need index data? for diffrent style as index?

Agreed.

  1. for my understanding, style_get could support the default style set if user didn't replace orignal eo property. is it right?

Indeed

another question,
now we create one factory, and create content object by this factory,
but sometimes we need callback on this content object.
e.g. button, checkbox...

now there are only one factory about image, but if we support others such as button or checkbox or radio
how we could add callbacks on each items?
how user konw that this callback is came from which item's index?

factory is really good idea and I like it but we should consider this matter for now.
have you any idea on this?

I have been thinking that the factory would emit an event with the created object, the array that define the connect, the target string and the index. If you want to add a callback, you would just register on that event and add your callback on demand.

Other example with some modifications with subhransu's points and with the addition of the eo_replace feature

In D3952#65562, @cedric wrote:

[snip]

  1. efl_model_connect, efl_model_factory_connect name looks very confusing. they don't have any model parameter but using model in class name so looks like model should used in the parameter. what about efl_ui_property_connect or binding then using model?

You are indeed correct. It should not be in the Efl.Model interface. Most likely part of Efl.Ui.Controller, no ? If so the name should be : efl_ui_controller_connect and efl_ui_controller_factory_connect.

And it is not! It is in efl_model_connect and efl_model_factory_connect, which uses the collapsing feature of Eolian to avoid the efl_model_connect_connect and efl_model_factory_connect_factory_connect. Which gives good function names for C, IMO.

They would be implemented by elm_layout and efl_model_connect interface(and consequently the same function name) by image.

  1. now style_get are passing index as a parameter, don't you think realized_event also need index data? for diffrent style as index?

Agreed.

Indeed.

  1. for my understanding, style_get could support the default style set if user didn't replace orignal eo property. is it right?

Indeed

I don't have an opinion on this. Would "default" work here? Maybe "item" instead ?

Regards,

In D3952#65563, @cedric wrote:

another question,
now we create one factory, and create content object by this factory,
but sometimes we need callback on this content object.
e.g. button, checkbox...

now there are only one factory about image, but if we support others such as button or checkbox or radio
how we could add callbacks on each items?
how user konw that this callback is came from which item's index?

factory is really good idea and I like it but we should consider this matter for now.
have you any idea on this?

I have been thinking that the factory would emit an event with the created object, the array that define the connect, the target string and the index. If you want to add a callback, you would just register on that event and add your callback on demand.

How about the factory have a function that would be overriden to register event callbacks on the item?

In D3952#65562, @cedric wrote:

[snip]

  1. now style_get are passing index as a parameter, don't you think realized_event also need index data? for diffrent style as index?

Agreed.

The Efl.Ui.List.Item_Event struct already have an int index field in this patch.

[snip]

In D3952#65562, @cedric wrote:

[snip]

  1. now style_get are passing index as a parameter, don't you think realized_event also need index data? for diffrent style as index?

Agreed.

The Efl.Ui.List.Item_Event struct already have an int index field in this patch.

An event is likely better.

[snip]

Thanks @cedric and @felipealmeida ,

now you create Selectable Model, and it looks like creating selectable property itself(if wrong, please tell me) so what about >>enable/disable? is it should model data also?

Yes and no :-) The idea is that sometimes you may want to display the same model accross different genlist. There was no way to >synchronize the selection among them. The idea with the selectable model is that if you do pass the selectable model, every genlist will >use it for the source of information to know what is selected. Meaning that if you are using a selectable model, if you select in one >genlist, it will happear selected in all other genlist.

If you don't use a selectable model, the selection become a property of the genlist and not anymore of the model.

Btw, we need a selection interface that we can then add to both genlist and selectable model. This would be used to manually select a >range or retrieve the current list of selected range.

I got it. I got your point about selectable model.
listview itself can control single select and mutliselect as like our genlist does, remember one address or store selected list on the eina_list.

But enable/disable looks uncleared.. ataully disabled state should be controlled as per item, so genlist item itself have disabled boolean varable in their data, but now data became an model. so what should we do? add disable state on each model child? or just memorize all disabled item in eina_list?(I don't think its good idea...)

  1. efl_model_connect, efl_model_factory_connect name looks very confusing. they don't have any model parameter but using model in class name so looks like model should used in the parameter. what about efl_ui_property_connect or binding then using model?

You are indeed correct. It should not be in the Efl.Model interface. Most likely part of Efl.Ui.Controller, no ? If so the name should be : efl_ui_controller_connect and efl_ui_controller_factory_connect.

And it is not! It is in efl_model_connect and efl_model_factory_connect, which uses the collapsing feature of Eolian to avoid the efl_model_connect_connect and efl_model_factory_connect_factory_connect. Which gives good function names for C, IMO.

They would be implemented by elm_layout and efl_model_connect interface(and consequently the same function name) by image.

I have less ideas on model feature, so I fallow most of your suggestion :), but still for me, it looks awkward... what about efl_apdater_model_connect and efl_adapter_model_factory_connect? that may helpful to understanding this feature is not model itself, on userside. I don't mind what name comes adapter, controller, or what else, about this feature but at least, this one should be distinguishable.

  1. for my understanding, style_get could support the default style set if user didn't replace orignal eo property. is it right?

Indeed

I don't have an opinion on this. Would "default" work here? Maybe "item" instead ?

Hmm actually, now I think this name need to be changed because we needs two style_set,
one is for listview scroller,
the other one is listview item which we already used.
so scroller(listview) style_set is came from the layout or elm_object(well I don't know it whould be changed efl_ui)
and listview itself have an method like item_style_set for set a style to it's item and user may can replace this method by eo_replace.
what do you think?

Hi,
After checking all possible usecase here are the below issue with factory and property binding.

To give you a background ,
To set a property in a object we need 3 things ( object , propertyname and value)

Model has some data like (model_key , value)
By doing model connect on layout ( part name , model_key ) we made sure the data which is associated with the model_key is for the underlying object( representing by the part_name, e.g. text or image(swallow)). But what we are missing is the property_name itself (like text_property or the level property in slider or state property in checkbox).

I can understand that there is not a single function like property_set() to handle this kind of scenario

For example
in efl_model_connect(e->layout, "elm.text", "name");
we assume that we are going to set the "text" property of the object (associated with "elm.text")
so we need to discuss more about it .

  1. If we use the factory only for creation of shallow object. who will interpret the model data ? .. factory cannot understand the model data so as the list view because listview doesn't know what kind of the object it is.

Ex : right now we are assuming the path data and the shallow object is image object, but think about scenario where we want to set the check box state property or slider value property.

So could you please add some example to address that use case.

  1. As factory is responsible for creation of object , if the model data changes regarding to the object (path change for image object or state change for slider ) how the new data will be applied to swallow object ?
  1. We still don't have clear idea how the user will get the event generated by the object (created by factory) as the object created by factory can be recycled for example a list view of 1000 items with single style and a window of 10 visible items , we may only create 10 swallow object and recycle it when we scroll.

Here I bring another topics,
weekend is coming so I think we've got enough time to consider many issues.

Now, move the sight to the tree and grouping.
The idea of making group and tree in MVC list are as felipe previously explained, depending on model hierarchy.
so the child model are also can have siblings and that hierarchy could be controlled grouping or tree interface.

We can choose two way.
one way is what genlist does. the sibling is also child item of listview so listview should now my model item count and child model item count both, and each item should created by parent listview itself like left picture.

the other way is in the chlid model, check there are sbling exist or not and create new sub-listview for this sibling models and the size of chlid item(group) is now became height of own item + size of sub-listview.

Somehow, we need to give easy interface to control this siblings for grouping and tree-viewing.
I think the second way looks more make sence if chlid-model hold their siblings.

what you think? please share your opinions.
Have a nice weekend and get some rest to refresh your long-way trip fatigue :)

Other example with some modifications with subhransu's points and with the addition of the eo_replace feature

In D3952#65562, @cedric wrote:

[snip]

  1. efl_model_connect, efl_model_factory_connect name looks very confusing. they don't have any model parameter but using model in class name so looks like model should used in the parameter. what about efl_ui_property_connect or binding then using model?

You are indeed correct. It should not be in the Efl.Model interface. Most likely part of Efl.Ui.Controller, no ? If so the name should be : efl_ui_controller_connect and efl_ui_controller_factory_connect.

And it is not! It is in efl_model_connect and efl_model_factory_connect, which uses the collapsing feature of Eolian to avoid the efl_model_connect_connect and efl_model_factory_connect_factory_connect. Which gives good function names for C, IMO.

Yes, but I complain about them being in efl.model.connect and efl.model.factory.connect class. I think they are missleading. Aren't they are part of the interface of a view ? So they should be in a meaningful namespace there. Maybe Efl.View.Connect and factory would be in Efl.Ui.View.Factory_Connect (as it only produce widgety stuff, and only if it make sense to split them, otherwise they could be both of them in Efl.Ui.View.Connect).

They would be implemented by elm_layout and efl_model_connect interface(and consequently the same function name) by image.

That is the interface name we dislike (efl_model_connect).

In D3952#65563, @cedric wrote:

another question,
now we create one factory, and create content object by this factory,
but sometimes we need callback on this content object.
e.g. button, checkbox...

now there are only one factory about image, but if we support others such as button or checkbox or radio
how we could add callbacks on each items?
how user konw that this callback is came from which item's index?

factory is really good idea and I like it but we should consider this matter for now.
have you any idea on this?

I have been thinking that the factory would emit an event with the created object, the array that define the connect, the target string and the index. If you want to add a callback, you would just register on that event and add your callback on demand.

How about the factory have a function that would be overriden to register event callbacks on the item?

I don't like abusing this. Especially when it makes sense that we can have more than one signal being setup. Event on the factory seems like the right solution in this case.

now you create Selectable Model, and it looks like creating selectable property itself(if wrong, please tell me) so what about >>enable/disable? is it should model data also?

Yes and no :-) The idea is that sometimes you may want to display the same model accross different genlist. There was no way to >synchronize the selection among them. The idea with the selectable model is that if you do pass the selectable model, every genlist will >use it for the source of information to know what is selected. Meaning that if you are using a selectable model, if you select in one >genlist, it will happear selected in all other genlist.

If you don't use a selectable model, the selection become a property of the genlist and not anymore of the model.

Btw, we need a selection interface that we can then add to both genlist and selectable model. This would be used to manually select a >range or retrieve the current list of selected range.

I got it. I got your point about selectable model.
listview itself can control single select and mutliselect as like our genlist does, remember one address or store selected list on the eina_list.

I think it is not even necessary as genlist can internally detect that the model it has been given does provide select property. If it doesn't it can just create internally a selectable model and use it. So no code duplication and simpler logic.

But enable/disable looks uncleared.. ataully disabled state should be controlled as per item, so genlist item itself have disabled boolean varable in their data, but now data became an model. so what should we do? add disable state on each model child? or just memorize all disabled item in eina_list?(I don't think its good idea...)

Oh, I forgot about enable/disable. I think we can solve it exactly the same way as selectable model. Just a enable model and in the same logic, if the model provided does provide that interface, genlist would just instanciate one internally.

As for simpler code and optimisation we could create a RangeModel which take a string as a property name and would provide a common infrastructure for both selectable and enable model (they would just inherit it with a custom constructor that set the range model property name). As a starting point, we can just use a list of index range. Later on we can optimize it to consume less memory and be more efficient (tree of group of range or something along that line).

  1. efl_model_connect, efl_model_factory_connect name looks very confusing. they don't have any model parameter but using model in class name so looks like model should used in the parameter. what about efl_ui_property_connect or binding then using model?

You are indeed correct. It should not be in the Efl.Model interface. Most likely part of Efl.Ui.Controller, no ? If so the name should be : efl_ui_controller_connect and efl_ui_controller_factory_connect.

And it is not! It is in efl_model_connect and efl_model_factory_connect, which uses the collapsing feature of Eolian to avoid the efl_model_connect_connect and efl_model_factory_connect_factory_connect. Which gives good function names for C, IMO.

They would be implemented by elm_layout and efl_model_connect interface(and consequently the same function name) by image.

I have less ideas on model feature, so I fallow most of your suggestion :), but still for me, it looks awkward... what about efl_apdater_model_connect and efl_adapter_model_factory_connect? that may helpful to understanding this feature is not model itself, on userside. I don't mind what name comes adapter, controller, or what else, about this feature but at least, this one should be distinguishable.

I agree with you, it should not be in the model API as this is definitively something that belong to either View or Controller side.

  1. for my understanding, style_get could support the default style set if user didn't replace orignal eo property. is it right?

Indeed

I don't have an opinion on this. Would "default" work here? Maybe "item" instead ?

Hmm actually, now I think this name need to be changed because we needs two style_set,
one is for listview scroller,

What do you expect listview scroller to provide ?

the other one is listview item which we already used.
so scroller(listview) style_set is came from the layout or elm_object(well I don't know it whould be changed efl_ui)
and listview itself have an method like item_style_set for set a style to it's item and user may can replace this method by eo_replace.
what do you think?

I am not to sure of the goal here to answer. Can you try to elaborate more ?

[snip]

Model has some data like (model_key , value)

By doing model connect on layout  ( part name , model_key ) we made sure the data which is associated with the  model_key  is for the underlying object( representing by the part_name, e.g. text or image(swallow)). But what we are missing is the property_name itself (like text_property or the level property in slider or state property in checkbox).

I can understand that there is not a single function like property_set() to handle this kind of scenario

In fact there is :-) Elementary widget will start to provide a connect interface. The string to connect property to will be part of the documentation. For example with efl.ui.image, we would have efl.ui.path and efl.ui.key as a connectable string.

[snip]

  1. If we use the factory only for creation of shallow object. who will interpret the model data ? .. factory cannot understand the model data so as the list view because listview doesn't know what kind of the object it is.

The widget it instantiate and the connect it does will be doing the work. You could if you want to change the behavior, inherit from one of the existing widget and change the possible connect.

Ex : right now we are assuming the path data and the shallow object is image object, but think about scenario where we want to set the check box state property or slider value property.

Swallow can be any kind of object. The connect being done by the factory depend on what the factory want to do. We will provide a set of default factory for image, video, entry and others as we improve the available widget, but you can write your own factory that provide your own widget.

So could you please add some example to address that use case.

  1. As factory is responsible for creation of object , if the model data changes regarding to the object (path change for image object or state change for slider ) how the new data will be applied to swallow object ?

The connect does trigger the update automatically. That is just fine and the point of connect. The only issue is if there is a change in style, but I think we shouldn't support that. Also when there is a a change in the index due to some deletion or insertion above the widget, we should trigger an event on the object itself. So if there is callback specific code handling things related to index, they should update their index on demand.

  1. We still don't have clear idea how the user will get the event generated by the object (created by factory) as the object created by factory can be recycled for example a list view of 1000 items with single style and a window of 10 visible items , we may only create 10 swallow object and recycle it when we scroll.

There isn't much issue here. I guess we can just trigger an event on the widget to tell it to disconnect from all model (This could be part of the efl.ui.*_connect interface). From there I think the easiest solution is for the factory to have a reconnect function that return the object and take one in parameter (It can decide to return a new one if it want).

weekend is coming so I think we've got enough time to consider many issues.

Not winter ? :-D

Now, move the sight to the tree and grouping.
The idea of making group and tree in MVC list are as felipe previously explained, depending on model hierarchy.
so the child model are also can have siblings and that hierarchy could be controlled grouping or tree interface.

We can choose two way.
one way is what genlist does. the sibling is also child item of listview so listview should now my model item count and child model item count both, and each item should created by parent listview itself like left picture.

the other way is in the chlid model, check there are sbling exist or not and create new sub-listview for this sibling models and the size of chlid item(group) is now became height of own item + size of sub-listview.

We were thinking about the second option and the model would have a depth property that will return where it does sit in the tree. The only open question I see with this solution is if group == -1 or group == 0. The rest should just work (tm).

Well summer is comming :p Too hot, bring me to the wall :{

about the style feature,
our listview still inherit style_set/get from layout, so this method means set a style for it's layout,
and this case is scroller.
we have few edc based feature in scroller side, especially about the handler and bar.
user can want to changing bar shape or enable to handle bar on touch,
so style_set/get on listview scroller is also necessary.

if this handler bar style is supported in other way, style_set/get may only need for item,
but still for me, object.style_set/get looks set an style about it's object not items.

  1. Factory and Event, still unclear for us, because at least, what event comes, and who send the event, user should know what item(index) or object are give this events, and control those event properly base on their index, so how will give this identify index to user by the factory interface? Please share some sample code for real usage of event handling for helping our understand.
  1. Now go to the real scenario, previous genlist are not control about data, so performance to bring data and memory usage are handled by user fully. they can customize data handling as their preference. Now we give the data handling interface model, so how user control their listview performance and memory usage as their preference in such case below,
    • (1) Performance is more important then Memory Usage.
    • (2) Memory Usage is more inportant then Performace.
    • (3) Resource is really limited so they need control performance and memory both.

I think this topic is related with model customization, now eo_replace could be one way to solve this but looks very dangerous in my view, because user need to understand all the role and scenario of replaced method. any idea for this?

Now I'll start the basic implementation about list except uncleared features such as factory.
thanks for every kind answers.

Regards.

This comment was removed by SanghyeonLee.
SanghyeonLee added a comment.EditedMay 23 2016, 5:04 PM

sorry for bring select and disable again but I need to make sure one thing percisely.
If select and disable are controlled by model, just user changing state of model child property and list will automatically update the view as their data changes.

but no-model used cases, we must give user some API to control this select and disable feature in list directly(such as efl_ui_list_item_select_set, efl_ui_list_item_disable_set or we could use some other feature in efl.ui.item) so here must come some "id" for item. now we don't give any item address to the user, so the other things that user control are integer index and child model.
do you agreed that select and disable feature come with it's integer index? or child model?
actually, this topic is not only about select and disable, also every controls about item in list.
In my view, index is the temporary value(it may changed by insertion and deletion, or reordering) and child model is the more proper identifying method for user and list both..

And.. as I see, we missed to discuss about scroll interface in previous meeting,
so is there any plan about scroll interface and scrolling object?
I guess the best result is most efl_ui_object itself can have scroll interface, but looks not easy,
then we also need to add one widget "efl_ui_scroller" as like elm_scroller.. and efl_scroll_interface must be re-implemented even it works same as elm_interface_scrollable.

Too many topics are left in here.. :p

singh.amitesh added a subscriber: singh.amitesh.
  1. Factory and Event, still unclear for us, because at least, what event comes, and who send the event, user should know what item(index) or object are give this events, and control those event properly base on their index, so how will give this identify index to user by the factory interface? Please share some sample code for real usage of event handling for helping our understand.

I am not to sure what is your interogation, but with efl_model, everything is index based. You even receive an index update if some item are inserted before an index position. Which event is unclear to you ?

  1. Now go to the real scenario, previous genlist are not control about data, so performance to bring data and memory usage are handled by user fully. they can customize data handling as their preference. Now we give the data handling interface model, so how user control their listview performance and memory usage as their preference in such case below,
    • (1) Performance is more important then Memory Usage.
    • (2) Memory Usage is more inportant then Performace.
    • (3) Resource is really limited so they need control performance and memory both.

This is the duty of the model, but by default there is now a huge different the model always provide data asynchronously to genlist and genlist doesn't hold any data at all except for what it display. So by default, we should consume less ressource and the framerate will remain high, just we will likely draw nothing while waiting for the data to be fetched.

In the future, we should implement some level of caching in the model that require it (Eio might as an imap model would also, but an avahi or a json would likely not). Also the caching is something very dependent on the underlying data that are manipulated. It will be much more efficient to do imap caching using local storage, while it might not be the best solution for Eio.

I think this topic is related with model customization, now eo_replace could be one way to solve this but looks very dangerous in my view, because user need to understand all the role and scenario of replaced method. any idea for this?

I think that is better optimized in each model and we may have a global interface to set memory consumption. Ideally, we should just integrate with EFL background and application priority change to do that automatically so that application never have to care about it.

Now I'll start the basic implementation about list except uncleared features such as factory.
thanks for every kind answers.

Thanks, what's the status ?

sorry for bring select and disable again but I need to make sure one thing percisely.
If select and disable are controlled by model, just user changing state of model child property and list will automatically update the view as their data changes.

but no-model used cases, we must give user some API to control this select and disable feature in list directly(such as efl_ui_list_item_select_set, efl_ui_list_item_disable_set or we could use some other feature in efl.ui.item) so here must come some "id" for item. now we don't give any item address to the user, so the other things that user control are integer index and child model.

Even in the case of using a model that provide general select/disable feature, it is necessary to provide this api in my opinion. They will just be binded with the above model (automatic internal one if necessary) as property and be changed based on the index (as this is the only way to access a model item). I am just not sure of the API name. The main issue with disable_set and select_set, is that they call for a _get. Maybe we would just want a way to enable/select and an iterator for both property ? As model property are async, it needs to be taken into account here (typically get is not async).

do you agreed that select and disable feature come with it's integer index? or child model?

Index, yes.

actually, this topic is not only about select and disable, also every controls about item in list.
In my view, index is the temporary value(it may changed by insertion and deletion, or reordering) and child model is the more proper identifying method for user and list both..

Not really as child model may not exist for that index. This is an completely dynamic mess ! :-D

@felipealmeida could you look at providing the data model that allow to add a select or enable property ? This would help for sure.

And.. as I see, we missed to discuss about scroll interface in previous meeting,
so is there any plan about scroll interface and scrolling object?
I guess the best result is most efl_ui_object itself can have scroll interface, but looks not easy,
then we also need to add one widget "efl_ui_scroller" as like elm_scroller.. and efl_scroll_interface must be re-implemented even it works same as elm_interface_scrollable.

Too many topics are left in here.. :p

Yes, let's create another place to talk about the scroller interface. General idea would be to have an efl.gfx.scroller for the interface or efl.scroller and an efl.ui.scroller for the widget.

How was vacation? I see some photos and that make me zealous :p

about the factory, I think there are some misunderstanding about factory between you, felipe and me, sub.
adding event in the factory is not a problem, but in that event, user sould know which indexed object is,
so how to handle it is the main problem we think. especially if content objects are re-used, same object pointer
could be used another index, so there must be some way to get index of list in this contents.
that is our question. factory is indivisual object itself, but now it could give index of model, and it looks very awkward.
Any solution about this? or is it totally misunderstanding of us about your event proposal?

BTW, I bring the question always, sorry for that,
here are another issues are exist about async-data handling.

now new model-interface are based on asyncronous(promise) data handle,
so get children slice also returned promise, get property data also returned promise.

In general scenarios,
in smart_calculation, list calculate which index need to be realized by their pan position,
so let's guessing index 1~10 item need to be realized,
and list create 10 layout with the style inputs,
...
the next step is updating texts, and contents,
so to get an index child, list ask children slice to model, and it return promise,
so child could comes ayncronously,
after chlid comes, list ask property text and content path on each chlidren,
and that also comes asyncronously.

then when list can calculate item's height properly? as we know,
list can only calculate proper height after get every texts and contents,
especially multiline cases.

so if list show the empty layout firstly and update it's in-contents later,
size need to be changed?

and how list can calculate whole list height? if non-homogeneous mode,
list need to calculate every item's size, but this can be done after model data load.

model basic concept about asyncronous is non-avoidable things now,
so if data comes too late, how list looks like, we should decide basic action.

I think I wrote too messy, I hope that you could understand the issue :(

and about the state of implementation, it is just beginning,
still there are no efl_ui_layout, or efl_ui_scroller exist, I use elm_layout and elm_interface_scrollable.
the first goal is creating scrollable list view with model text data with realize/uinrealize concept
without any state or mode support.
I'll create new patch about this soon.

Additionally,

@felipealmeida and @cedric
actually, I can't understand this children_slice_get,
why this API should asyncronous? even request time, child model could be not exist yet, yes,
but now the properties are asyncronous,
so just creating child model and return when it requested is not a big job.

let's think about one problem of this APIs,
if I'm asking start 10 and count 10 child, so I expect get 10~20th model child.
but before the promise_then calls, childrens are inserted between 10~20th,
then what children should return in this promise_then?
orignal 10~20th? or updated 10~20th? both looks awkward in my view.
this is not only multiple chlidren get problem. even single child_get,
index could be updated between actaully API calls and then callback comes,
so I cannot guarantee my index-to-child.
property asyncronous, great, but chlid, hmmmm I'm not sure.
too much asyncronous concept makes too complicate model itself.
I'm not complain about lazy creation about child, but at least, if I can get count of child,
I should get proper indexed child. that should guaranteed by model....
is there anything that I misunderstanding?
or any good solution?

sorry for disturbing you and thanks for every help.

Let's think about the syncronous model usage, (by user-demands)

  1. dragging is happen(pan is changed)
  2. smart_calculate is called
  3. new item realized
  4. load property by promise(even syncronous case :p)

promise = property_get();
eina_promise_then(promise, ... _then_cb, ..);

  1. render the object : not update property yet.
  2. _then_cb is called by event handling
  3. smart_calc
  4. render the object : update property

In my understand, promise is also new event callback for asyncronous, so like job,
this callback will be called in next main loop, and it occur one non-updated render image.
am I correct? is there any solution to call promise callback directly for syncronous model by user demands?

cedric added a comment.Jun 1 2016, 1:35 PM

about the factory, I think there are some misunderstanding about factory between you, felipe and me, sub.
adding event in the factory is not a problem, but in that event, user sould know which indexed object is,
so how to handle it is the main problem we think. especially if content objects are re-used, same object pointer
could be used another index, so there must be some way to get index of list in this contents.
that is our question. factory is indivisual object itself, but now it could give index of model, and it looks very awkward.
Any solution about this? or is it totally misunderstanding of us about your event proposal?

This is not something user will need to care for most of the time. When you do connect a specific property to your model, this will stay connected on that specific index. It will keep updating the widget properly and automatically by listening on the model event. In the factory code, you create your widget and connect it to the model. There it will just continue to work nicely and you have nothing else to do.

BTW, I bring the question always, sorry for that,
here are another issues are exist about async-data handling.

Did you give a look at what carsten did on elementary store or something like that ? It was a fully asynchronous use of genlist with the same constraint as below.

now new model-interface are based on asyncronous(promise) data handle,
so get children slice also returned promise, get property data also returned promise.

[snip]

then when list can calculate item's height properly? as we know,
list can only calculate proper height after get every texts and contents,
especially multiline cases.

It needs to calculate its height at the time of the rendering with the data it already had received. The thing that is missing in our proposal right now is an event that tell you when all the connected property have received a value. Ideally this doesn't means it is stable and the widget could get later on a new size at any point in time... Which is quite annoying, but yes, the list will continuously resize.

so if list show the empty layout firstly and update it's in-contents later,
size need to be changed?

Yes.

and how list can calculate whole list height? if non-homogeneous mode,
list need to calculate every item's size, but this can be done after model data load.

Basically I would go over the list wait to have enough information on each created object (when all property are connected and fetched with the event we don't have right now), use that as the item size, destroy the widget and remember the item size. This way you can continue doing the same thing as before.

model basic concept about asyncronous is non-avoidable things now,
so if data comes too late, how list looks like, we should decide basic action.

Yes, the factory can set a default state and when the connect happen the state will be changed properly. This is expected and the only way to have really fast scrolling. 100% asynchrone.

I think I wrote too messy, I hope that you could understand the issue :(

Hope you can understand my answer ! I really wish you guy where in France for that meeting. I did request your presence would have been really useful... Anyway !

and about the state of implementation, it is just beginning,
still there are no efl_ui_layout, or efl_ui_scroller exist, I use elm_layout and elm_interface_scrollable.
the first goal is creating scrollable list view with model text data with realize/uinrealize concept
without any state or mode support.
I'll create new patch about this soon.

Yes, I need to work on efl.ui.layout. Also @felipealmeida could you work on the model connect interface ? This would really be useful right now :-) @SanghyeonLee, can you look at making the efl.ui.scoller happen as I think nobody is working on it and you may well be the guy who use it the most.

cedric added a comment.Jun 1 2016, 1:47 PM

Additionally,

@felipealmeida and @cedric
actually, I can't understand this children_slice_get,
why this API should asyncronous? even request time, child model could be not exist yet, yes,
but now the properties are asyncronous,
so just creating child model and return when it requested is not a big job.

To be fast, we need to be 100% asynchronous. This way we can make all the blocking operation happen in another thread and make sure we always have 60fps. It does have tradeoff, especially in complexity. We are trying to limit that complexity on developer, but there is so much we can do there. The other tradeoff is that we will accept to render UI where the final content is not ready yet.

let's think about one problem of this APIs,
if I'm asking start 10 and count 10 child, so I expect get 10~20th model child.
but before the promise_then calls, childrens are inserted between 10~20th,
then what children should return in this promise_then?
orignal 10~20th? or updated 10~20th? both looks awkward in my view.

In my opinion, you should get the original 10~20 items you requested, but with an updated position. So they may well be 10~13, 18~19, 25, 28~32 and so on. If we can't get the actual index of the returned child model, then that should be fixed.

this is not only multiple chlidren get problem. even single child_get,
index could be updated between actaully API calls and then callback comes,
so I cannot guarantee my index-to-child.
property asyncronous, great, but chlid, hmmmm I'm not sure.
too much asyncronous concept makes too complicate model itself.
I'm not complain about lazy creation about child, but at least, if I can get count of child,
I should get proper indexed child. that should guaranteed by model....
is there anything that I misunderstanding?
or any good solution?

Nop, you are completely correct. So for example with Eio data model. We don't know the number of child until we have listed the full content of the directory. It is unacceptable to wait on it. Imagine you are on a network directory, this is going to block forever. So you need this to be asynchronous, but if you want the model to sort the file in that directory... You need to be able to insert this new child randomly in the parent model. Eio is the perfect example of a data model that push things to the limit, but this would apply on an IMAP data model or actually any IO based data model.

sorry for disturbing you and thanks for every help.

Don't worry that's the point of this page. I wish we could have done it more efficiently, but well...

syncronous qeustion is solved after checking eina_promise,
sorry for bothering this.
if data is ready in model side,
promise has finished, so it calls callback directly right?
then there are no 1 additional loop needs.

SanghyeonLee added a comment.EditedJun 2 2016, 1:09 AM

@felipealmeida,
one question about children_slice_get docs,

it takes start, and count, and in the doc, it explain if start is 3 and count is 4 then,

child0 [no]
chlid1 [no]
child2 [yes]
child3 [yes]
child4 [yes]
child5 [yes]
child6 [no]

why start is 3, but it start index of 2? I think.... the start must be same space of index, if not, people confused about the start value and index.... any reason for this? or doc is wrong?
@cedric, @smohanty what do you think abt it? As you know, I've already got too many complain about index start value in genlist and gengrid(it start from 1 and eina_list start from 0), so I want to avoid such situation now, all index system in efl must unified one.

I think you want to avoid -1 usage to make model have much more item-by unsigned int inputs, but in that case... hmm... just give 0 count also enough i think... well it's point of view, but as I told you, if the index system is different as user expected, especially just one API, people complain about it.

cedric added a comment.Jun 2 2016, 3:19 PM

@cedric, @smohanty what do you think abt it? As you know, I've already got too many complain about index start value in genlist and gengrid(it start from 1 and eina_list start from 0), so I want to avoid such situation now, all index system in efl must unified one.

Yes, fully agree. It needs to be fixed.

jpeg added a comment.Jul 11 2017, 6:35 PM

@felipealmeida please abandon and refer to T5355 and D4986

zmike commandeered this revision.May 2 2018, 4:14 PM
zmike abandoned this revision.
zmike added a reviewer: felipealmeida.