Page MenuHomePhabricator

elm: efl_ui_list partial implementation
AbandonedPublic

Authored by felipealmeida on Jun 23 2017, 11:00 AM.

Details

Summary

efl_ui_list implementation

Diff Detail

Repository
rEFL core/efl
Branch
devs/felipealmeida/efl_ui_list
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 3988
Build 4053: arc lint + arc unit
felipealmeida created this revision.Jun 23 2017, 11:00 AM
  1. state contols (select/focus/disable/visible) It good that Promise will be more better interface then now, cool. but still I think basic widget properties and states such as (select, focus, enable, visible) are maintained by view side not by the model data.

    Moreover, I think these data should be handled and stored in list widget itself in Efl_Model_Item structure not stored in model data. We will have few model-based item widget, not only list, tree(will be discussd), grid and all these widget will have common feature about this state controls, so I suggest to have some common abstract class wihch can be inheritted to these model based item widgets and support common features.

    I guess now some common item features are under the discussion on T5567 and could be states also discussed in there. obiously efl_ui_list need to inherit them and support common APIs. if there are any discussion about this subject in EDD, please share them.

    -> This looks Item Factory Feature Job and need to discuss more detail in there not list side. list need to fallow common item based feature. Due Date: Aug. 3th Week

By MVVM pattern, what is passed to efl_ui_list is a ViewModel which contains information about the Model itself but also information
about view in a way to customize how information is going to get presented. So, in that spirit, "selection" is a property of the ViewModel.

What we need, however, is a way for applications to easily create ViewModels from Data Models in a way that is easy to customize
View information. So, I really don't see why we would need callbacks or other ways to do this if the user can create ViewModels.

The other properties of view: "focus, enable, visible" are a property of the elm_layout itself, which the item inherits from. So, the
user can disable, freeze, set focus, make unfocusable and make it visible or not just by setting those properties on the elm_layout
they are handed to in realize event. Is there a problem with that in principle? I don't think we need efl_ui_list specific code for this,
since the user can just access it directly in elm_layout of the item itself. But, maybe, we should have a item,visible event so the
user can customize how a item is going to appear just before it appears, but where position and size information will already
be ready and set in elm_layout for the item.

The efl_ui_list has "item,focused/unfocused", "item,highlighted/unhighlighted" and "item,selected/unselected". I'm not sure
these signals should exist. IMO, these should property_sets on ViewModel only.

1.2) Item Layout

Not sure what will do on item factory which was discussed in T5567, but the thing that I worried is,
yes they can resize, move, do everything on this view object and sometimes this kind of access is highly required by user demands,
 
(if they really know what they do)
but at least, they can't, shoudn't remove this layout object. we should block this thing anyhow, set ref count or block API calls,
don't know but it should be not allowed.

I'm not sure if that is really possible. Is it @cedric ? Maybe we could reset reference counting after realize/unreliaze events or
freeze object destruction while calling the callback. Or we can override destructor and make object get back to life with
efl_ref until efl_ui_list is not destroyed.

But, aside from destruction, is access to elm_layout directly a good thing, then @SanghyeonLee ? If only destruction is a
problem, I think this is something we can workaround with Eo. If, however, you feel that direct access to elm_layout might
be a problem because users can make some other errors, then we may need to discusss if leaving access to elm_layout is
a good thing or not. I, personally, feel that it is useful to give access to elm_layout directly and makes life easier for
application developers which don't have to go through lots of indirection so they can finally do what they need to do.

1.3) Factory Inheritance

Could be handled by eo_super in create funcion by inherited new eo class, if we giving some easy custom way on eo.
but one of main reason of factory thing is giving more easy way of user experience about repeated jobs,
and for now, creating custom eo class is not that easy as I think... create eo files and understand eo concepts...
hopely, heavy user should do that kind of things, but we should not expect that kind of thing to our general factory user in my thought.
if it could be much simpler, then, yes. that is still right way on OOP. I agreed about that point. but now its not easy for them is my worries.
 
-> Conceptionally you are right, but currently it's too difficult to create customized factory eo class in user side. any other suggestion?
Due Date: Aug. 3th Week

So, with eo_override, it should be a lot easier for C users to create inheritances from Eolian classes. In C#, it is just know which class
you need to inherit, no need to create .eo files or anything. So, I think this is more a documentation problem than a usability problem.
The resources for easy inheritance already exist, people just need to use it.

SanghyeonLee edited edge metadata.Jun 23 2017, 11:57 AM
  1. state contols (select/focus/disable/visible) It good that Promise will be more better interface then now, cool. but still I think basic widget properties and states such as (select, focus, enable, visible) are maintained by view side not by the model data.

    Moreover, I think these data should be handled and stored in list widget itself in Efl_Model_Item structure not stored in model data. We will have few model-based item widget, not only list, tree(will be discussd), grid and all these widget will have common feature about this state controls, so I suggest to have some common abstract class wihch can be inheritted to these model based item widgets and support common features.

    I guess now some common item features are under the discussion on T5567 and could be states also discussed in there. obiously efl_ui_list need to inherit them and support common APIs. if there are any discussion about this subject in EDD, please share them.

    -> This looks Item Factory Feature Job and need to discuss more detail in there not list side. list need to fallow common item based feature. Due Date: Aug. 3th Week

By MVVM pattern, what is passed to efl_ui_list is a ViewModel which contains information about the Model itself but also information
about view in a way to customize how information is going to get presented. So, in that spirit, "selection" is a property of the ViewModel.

What we need, however, is a way for applications to easily create ViewModels from Data Models in a way that is easy to customize
View information. So, I really don't see why we would need callbacks or other ways to do this if the user can create ViewModels.

The other properties of view: "focus, enable, visible" are a property of the elm_layout itself, which the item inherits from. So, the
user can disable, freeze, set focus, make unfocusable and make it visible or not just by setting those properties on the elm_layout
they are handed to in realize event. Is there a problem with that in principle? I don't think we need efl_ui_list specific code for this,
since the user can just access it directly in elm_layout of the item itself. But, maybe, we should have a item,visible event so the
user can customize how a item is going to appear just before it appears, but where position and size information will already
be ready and set in elm_layout for the item.

The efl_ui_list has "item,focused/unfocused", "item,highlighted/unhighlighted" and "item,selected/unselected". I'm not sure
these signals should exist. IMO, these should property_sets on ViewModel only.

Model handles data, and selection, focus, visibility, disability, all these kind of states looks also data, and also its 'state' of view which need to be rendered.
so I think those state have both "view" and "model" attribute, but I think it's more close to view side.
when its confused, we could refer the pre-structure of other framework.
they had same questions and the current implementation could be the result of those worries.

  1. in QT :

http://doc.qt.io/qt-4.8/qlistview.html
they have QlistView class and selection is handled by model 'but'
http://doc.qt.io/qt-4.8/qitemselectionmodel.html#details
they give QItemSelectionModel which provides all seleciton handles to user.
also ListView itself have seleciton hadles in private members.

  1. in Android

https://developer.android.com/guide/topics/ui/layout/listview.html
ListView get data form adapter which is conceptually same as model(not 100% though..)
https://developer.android.com/reference/android/widget/Adapter.html
but the selection is handles by listview itself in public member.
https://developer.android.com/reference/android/widget/ListView.html

  1. in Xamarin which is highly related with efl in tizen native

https://developer.xamarin.com/guides/xamarin-forms/user-interface/listview/data-and-databinding/
are also very simple MVC listview,
https://developer.xamarin.com/guides/xamarin-forms/user-interface/listview/interactivity/
and selection is given by listview itself.

not searched gtk or ios yet, but I think they would do same thing.
mostly list itself provide state hadler feature and user don't care about data in model - not sure in android and xamarin cases those selection is stored in model and shared in other widget also...
or provide some well-defined model about selection or states, so user don't need to consider to create those data and accessing them,
just using provided features, and also model can directly connected to other view with those states shares in qt.

not sure all of these states are need to be properties of model, but at least, I think we should give some nice model class for them to provide it as an model data.

SanghyeonLee added a comment.EditedJun 28 2017, 7:09 PM

1.3) Factory Inheritance

Could be handled by eo_super in create funcion by inherited new eo class, if we giving some easy custom way on eo.
but one of main reason of factory thing is giving more easy way of user experience about repeated jobs,
and for now, creating custom eo class is not that easy as I think... create eo files and understand eo concepts...
hopely, heavy user should do that kind of things, but we should not expect that kind of thing to our general factory user in my thought.
if it could be much simpler, then, yes. that is still right way on OOP. I agreed about that point. but now its not easy for them is my worries.
 
-> Conceptionally you are right, but currently it's too difficult to create customized factory eo class in user side. any other suggestion?
Due Date: Aug. 3th Week

So, with eo_override, it should be a lot easier for C users to create inheritances from Eolian classes. In C#, it is just know which class
you need to inherit, no need to create .eo files or anything. So, I think this is more a documentation problem than a usability problem.
The resources for easy inheritance already exist, people just need to use it.

1.2) Item Layout

Not sure what will do on item factory which was discussed in T5567, but the thing that I worried is,
yes they can resize, move, do everything on this view object and sometimes this kind of access is highly required by user demands,
 
(if they really know what they do)
but at least, they can't, shoudn't remove this layout object. we should block this thing anyhow, set ref count or block API calls,
don't know but it should be not allowed.

I'm not sure if that is really possible. Is it @cedric ? Maybe we could reset reference counting after realize/unreliaze events or
freeze object destruction while calling the callback. Or we can override destructor and make object get back to life with
efl_ref until efl_ui_list is not destroyed.

But, aside from destruction, is access to elm_layout directly a good thing, then @SanghyeonLee ? If only destruction is a
problem, I think this is something we can workaround with Eo. If, however, you feel that direct access to elm_layout might
be a problem because users can make some other errors, then we may need to discusss if leaving access to elm_layout is
a good thing or not. I, personally, feel that it is useful to give access to elm_layout directly and makes life easier for
application developers which don't have to go through lots of indirection so they can finally do what they need to do.

Actually I thought that eo_override was gone,
When I saw them it was really easy to use but disappeared for a little, and can't sure it's still same usage, but if it is like that super easy, good idea.
and obviously this is much better then hiding object, previously we give fake tracking object to tracking item view object geometry on user, and, don't need to do that now.

If they really want to modify full layouting or visual effect on widget, they can customize widget class by inherit them, but for simple purpose, layout overriding is fine.

I've chatted with @cedric , and we should also implement the Efl.Ui.Pack.Layout on efl_ui_list itself too.

Also, we should be relaying some of the events on the items to the list itself.

BTW, since model_set is always going to be done on elm_layout of the item, you can always get the children model of the item by just doing model_get on elm_layout.

We also discussed about having a factory for elm_layout so user can customize how elm_layout can be generated by users, etc.

So, we are working with the points mentioned before + the modifications that I mentioned now and the dicussion with @cedric and I'll try to show something new this week on efl_ui_list.

Also, we are working on an algorithm which will not need a homogeneous mode.

Yeah, factory by layout looks good way to me, more flexible and if factory itself manages the object life-cycles(caching), list code goes much clear.
model child can be get by layout, but not sure which data will be represented list indexed-item now, I think model-child could be but if it is hided and can get by layout itself then...
but layout cannot represent item itself cause it is only valid in current visible period, and once it was gone, I don't know factory or list how to managing them,
but could be reused in other area also.
It is also highly tighten on other item-feature but I think it is model based view widget so it would be not a problem that we having a model-based one..

anyway, I'm curious about the new algorithm without homogeneous. I'll be wait your new updates.
I'm also do some grid job in my private workplace and soon, list class will be more cleared, I'll update that also.
I think we might need some abstract class as our final goal as a common parent to combine list and grid and other model based scroll-layout views.

and I think you might see the mail thread(though I didn't answer the mail sincerely now...) we've discussed about the naming about 'grid' and 'list'...
and might be recommended that suggestions.

Sum up,

  1. elm.layout -> Efl.Ui.Pack.Layout
  2. Efl.Ui.Pack.Layout.Factory also could be needed.
  3. new list calcaution algorithm without homogeneous.

third one is really what I expected. now I'm trying to apply new sizing algorithm in grid view but if new list algorithm is useful in grid view, I could arrange them to grid view also.

Thanks for fast updating. I'll wait your new update :)

Hello, just one minor notice, this here still uses the old focus api, which will be removed in the next release cycle, could you use efl.focus.manager and the likes?

On a matter on how many features from genlist/grid you like to port over, my understanding would have been to put the items into one manager, and the widgets into a other, and then switch depending on where the focus should be to the correct manager. (At least, thats what i am currently trying to introduce in gengrid)

jpeg added a subscriber: zmike.Jul 3 2017, 6:44 AM

Sum up,

  1. elm.layout -> Efl.Ui.Pack.Layout

Correction: elm_layout will become Efl.Ui.Layout.
Pack is now used for Box & Table APIs, where objects are packed together. I'm not even sure the "pack" word itself is appropriate for them, but that's a question about English.

  1. Efl.Ui.Pack.Layout.Factory also could be needed.

So,Efl.Ui.Layout.Factory
I wonder what exactly it would do. If it already knows about the file & group then it would probably be easy to use (most likely just bind some strings), otherwise I'm afraid getting that info from a model could be harder.

  1. new list calcaution algorithm without homogeneous. third one is really what I expected. [...]

I'm expecting that as well! :) I wonder how the size calculation would be done without creating the items. Of course you can take a fuzzy approach and that would probably been good enough for most use cases.

Recently @zmike complained to me about the genlist reusable item API, as he was expecting those items to be immediately reusable without changing their properties (like text, image parts), in other words cached forever. The documentation on this API is quite poor indeed and it's not clear that it's only about caching some complex objects but not really their contents. Are we planning a way to keep items indefinitely in cache or would that be too risky?

Hello, just one minor notice, this here still uses the old focus api, which will be removed in the next release cycle, could you use efl.focus.manager and the likes?

On a matter on how many features from genlist/grid you like to port over, my understanding would have been to put the items into one manager, and the widgets into a other, and then switch depending on where the focus should be to the correct manager. (At least, thats what i am currently trying to introduce in gengrid)

Yeah obviously new interfaces and widget need to using new focus manager and it is just proposal thing to how new list view will be implemented. yet many things are not done including focus and selections and highlight features in detail.

In D4986#84291, @jpeg wrote:

Sum up,

  1. elm.layout -> Efl.Ui.Pack.Layout

Correction: elm_layout will become Efl.Ui.Layout.
Pack is now used for Box & Table APIs, where objects are packed together. I'm not even sure the "pack" word itself is appropriate for them, but that's a question about English.

Yeah. ok. Efl.Ui.Layout and actually I'm not sure that we fellipe said we have to implement those widget, what level he mentioned. Maybe 'we' is including cedric also, cause as I checked, layout is working on cedric side...

  1. Efl.Ui.Pack.Layout.Factory also could be needed.

So,Efl.Ui.Layout.Factory
I wonder what exactly it would do. If it already knows about the file & group then it would probably be easy to use (most likely just bind some strings), otherwise I'm afraid getting that info from a model could be harder.

Acutally, also it looks ambiguous yet to me, especially how it gives some methods in end-user side. looks we share same worries.
The main purpose of these model based list re-implements are based on benefits of usabilities, we should never forget that things...

  1. new list calcaution algorithm without homogeneous. third one is really what I expected. [...]

I'm expecting that as well! :) I wonder how the size calculation would be done without creating the items. Of course you can take a fuzzy approach and that would probably been good enough for most use cases.

Recently @zmike complained to me about the genlist reusable item API, as he was expecting those items to be immediately reusable without changing their properties (like text, image parts), in other words cached forever. The documentation on this API is quite poor indeed and it's not clear that it's only about caching some complex objects but not really their contents. Are we planning a way to keep items indefinitely in cache or would that be too risky?

you meant the reusable_content_get callbacks? I know its very nasty feature, but generally the reason that it implemented like that is firstly we didn't care about many resuable cases in genlist, I meant the fault that we did in content_get callbacks, and our c-based feature cannot gives overrides, so we didn't have many choices in legacy, but yes. it's bad way. and I agree that I need to fill the documents more details.
but in new interfaces, content_get will be gone, and item will be gone, and all the thing will be controlled by factory, and as my understanding, factory can also do the object caching themselves (I don't know how they usefully reset the states or restore states in caches), so if really that works is well done, problem will be solved. and I hope so.

@felipealmeida
we need to speed up, so could you please explain about your the algorithm briefly?
and still many works and goals are ambiguously as I see, so we need to make sure our R & R,
so I'll send a mail by official channel soon.

And, I did some profiling of old genlist gengrid thing and proposal of model-view based list diagrams.

This is old genlist and gengrid class diagrams. some inherited features and pan-scroll feature are skipped.

Here is new proposal of new model-view based list class diagram, also some feature are skipped and some classes and interfaces are not matched in current implementation.
if its too much wrong then please mention it, and @bu5hm4n actually when I write it, I didn't checked new focus manager things so just put focusable interface, but this need to changed your interface.

The new class diagram is wrriten by plantUML, which I recently found and really likes, it generates diagram by the pseudo code, you can see the my code in here
thanks.

In D4986#84291, @jpeg wrote:

Sum up,

[snip]

  1. Efl.Ui.Pack.Layout.Factory also could be needed.

So,Efl.Ui.Layout.Factory
I wonder what exactly it would do. If it already knows about the file & group then it would probably be easy to use (most likely just bind some strings), otherwise I'm afraid getting that info from a model could be harder.

The idea is that you could actually connect on the factory itself, which would then relay the connection to the elm_layout when it creates it. So you don't really need to listen to realize events anymore. The factory would do that automatically, making it easier to work. The realize, however, can be used if the user needs more control.

  1. new list calcaution algorithm without homogeneous. third one is really what I expected. [...]

I'm expecting that as well! :) I wonder how the size calculation would be done without creating the items. Of course you can take a fuzzy approach and that would probably been good enough for most use cases.

It is a fuzzy approach based on average item size which gets recalculated when new resize events are received. For homogeneous, if no resize would happen after the first elements get drawn (with layout reuse), then overhead would be diminished considerably since no recalculations would need to happen anymore.

Recently @zmike complained to me about the genlist reusable item API, as he was expecting those items to be immediately reusable without changing their properties (like text, image parts), in other words cached forever. The documentation on this API is quite poor indeed and it's not clear that it's only about caching some complex objects but not really their contents. Are we planning a way to keep items indefinitely in cache or would that be too risky?

Well, there are two approaches possible. I'm not sure which is the best:

  • efl_ui_list handles and owns layouts directly, reusing them.
  • efl_ui_list returns layouts from factory and creates new ones when it needs it.

We're implementing the first case first. I think it makes for a better reusability and allows the developer to reuse all widgets he wants it. The developer can use a mix of efl_key_data and realize/unrealize events. The user can attach state to Layout objects through efl_key_data that pertains to caching, for example.

The second case, OTH, allows for a different kind of cache, one about all Layout objects. It seems a nice thing, but way overkill for what efl_ui_list already can do easily. We could, however, have both ways with a factory that just return the same object. The problem here is: which state should the layout be given to efl_ui_list? On efl_ui_list owning, the layout will be in the state that unrealize event returns it and is completely up to the developer to be able to reuse it in realize. Or we could have a third event realize,item,cached event, if the event is not listen to, then the efl_ui_list destroys it (gives back to factory), otherwise reuse it.

Regards,

@felipealmeida
we need to speed up, so could you please explain about your the algorithm briefly?
and still many works and goals are ambiguously as I see, so we need to make sure our R & R,
so I'll send a mail by official channel soon.

See my other reply about homogenous. I'll try to upload another diff today, Brazil time. If, however,
I do not, I'll during the weekend.

About Focus Manager: Yeah, we will fix it asap.

About other genlist features: Which other features in genlist are essential to efl_ui_list besides: selection, focus, visibility, disability, lazyness and homogenous mode are you worried? Please list them so we can talk about each one specifically. The above ones we are already working on them and I'll upload asap some progress on it.

thanks.

woohyun edited edge metadata.Jul 9 2017, 6:43 PM

@felipealmeida
we need to speed up, so could you please explain about your the algorithm briefly?
and still many works and goals are ambiguously as I see, so we need to make sure our R & R,
so I'll send a mail by official channel soon.

See my other reply about homogenous. I'll try to upload another diff today, Brazil time. If, however,
I do not, I'll during the weekend.

@felipealmeida

About Focus Manager: Yeah, we will fix it asap.

About other genlist features: Which other features in genlist are essential to efl_ui_list besides: selection, focus, visibility, disability, lazyness and homogenous mode are you worried? Please list them so we can talk about each one specifically. The above ones we are already working on them and I'll upload asap some progress on it.

thanks.

@felipealmeida Hello :)

I think @SanghyeonLee wants to list up all the works for the future genlist(=efl_ui_list) + future gengrid,
and to separate them for you people and for him properly to do the work parallelly at the same time.

@SanghyeonLee could you list up all the details you are thinking now ?
Then, @felipealmeida will give the comment on them whether he needs to handle it or not.

Let's go go :)

Hello :) Late Answer, sorry for that.

  1. Efl.Ui.Pack.Layout.Factory also could be needed.

The idea is that you could actually connect on the factory itself, which would then relay the connection to the elm_layout when it creates it. So you don't really need to listen to realize events anymore. The factory would do that automatically, making it easier to work. The realize, however, can be used if the user needs more control.

Yeah, still realize needs for user demands on any cases. but connection will be automatically done by list itself. agreed.
then.... one more questions, if user need very complexed-view like multiple-different styles, or every different swallow area depending on their index what they can do? overriding is only way for that? and one list view can have only one single factory for view creation?
so what I'm asking is, do you think that list view and factory need to be 1 to 1 relationships or 1 to N relationships (N is not a number of items, but number of styles or forms they needed to create their view)?

  1. new list calcaution algorithm without homogeneous.

It is a fuzzy approach based on average item size which gets recalculated when new resize events are received. For homogeneous, if no resize would happen after the first elements get drawn (with layout reuse), then overhead would be diminished considerably since no recalculations would need to happen anymore.

so you meant guessing every items are having same size (like homogeneous) and if resize if called, and size is different then you have, update them right?
hmm... not sure pretty.. actually main reason current calculation load is heavy in list is based on edje calculation itself not list view size calculation.
and it calls too much resize calls (so current genlist only re-calculate forcely it once and never change their size again... )
so basically your idea of new resize event means, the object do size calculation itself, which we don't really want to avoid in homogeneous cases. so I think still we need homogeneous mode. mostly every item have same size(at least same style items) in list view, so they don't need to do edje calculation at all.
furthermore, the new idea is kind of trade-off, that move size calculation time to item realizing from begin of view creation.
view creation will effect creation delay. but if we move this thing to item realizing, the scroll frame will be dropped.
so, yes. we should find out some better timing to do calculation, and basic idea looks good.
but still l think homogeneous is better for most cases - if I'm wrong - could be I misunderstand your idea, please tell me.
and we should not makes any frame drops by these size calculation - which is most important. sadly, but we should give best performance even in low quality environments.

Recently @zmike complained to me about the genlist reusable item API[....],

Well, there are two approaches possible. I'm not sure which is the best:

  • efl_ui_list handles and owns layouts directly, reusing them.
  • efl_ui_list returns layouts from factory and creates new ones when it needs it.

    We're implementing the first case first. I think it makes for a better reusability and allows the developer to reuse all widgets he wants it. The developer can use a mix of efl_key_data and realize/unrealize events. The user can attach state to Layout objects through efl_key_data that pertains to caching, for example.

    The second case, OTH, allows for a different kind of cache, one about all Layout objects. It seems a nice thing, but way overkill for what efl_ui_list already can do easily. We could, however, have both ways with a factory that just return the same object. The problem here is: which state should the layout be given to efl_ui_list? On efl_ui_list owning, the layout will be in the state that unrealize event returns it and is completely up to the developer to be able to reuse it in realize. Or we could have a third event realize,item,cached event, if the event is not listen to, then the efl_ui_list destroys it (gives back to factory), otherwise reuse it.

Yes, currently, first one make more easier obviously.
If we really create an items view by layout factory, I think reuse need to be implemented in factory side, but before that kind of interface supporters, we have no choices.
but factory handles object creations, and I think they could handles deletion also I think, so by the concepts, it makes more sense to me that factory treat the object caching things and states / contents initializations.
also for these, we might need some better initialize method about class, including inits individual states, and text, and contents as user demands.
if then, list have some other usages, they could override factory's cache feature and re-implement all.
these are need to discuss with other people I think. need to get more idea and need to make some efl ui common feature for cache /reuse / init.

Regards,

Thank you.

SanghyeonLee added a comment.EditedJul 10 2017, 11:39 PM

I think I missed one core feature in my previous mail and my class diagram both, the view model( proxy?). I'm not sure who is working on it and how it will come.
but basically on my understand about MVVM, view model will give abstract interfaces binding on view side, so select, visible, disable, some common view element which controls by model can be exsit in the proxy level.
This might be confused you cuase my previous opinion about states is on view side...
But yeah, still view can also wrapping this state controls cause they might want to give their own feature of state control( such as select policy or mode ).

so the view model(proxy) is also in our plan and final structure of efl.ui.view is connected by view model not model right?

cedric edited edge metadata.Jul 11 2017, 10:02 AM

I think I missed one core feature in my previous mail and my class diagram both, the view model( proxy?). I'm not sure who is working on it and how it will come.
but basically on my understand about MVVM, view model will give abstract interfaces binding on view side, so select, visible, disable, some common view element which controls by model can be exsit in the proxy level.
This might be confused you cuase my previous opinion about states is on view side...
But yeah, still view can also wrapping this state controls cause they might want to give their own feature of state control( such as select policy or mode ).

My current opinion on ViewModel (proxy) for select, visible and enable state, is that the ListView will probe the model it is being given for this property. If there isn't any property like that on the model, it will automatically insert a ViewModel that handle that information. This way the code of the ListView is always the same and doesn't depend on what the Model provide. Additionnally we need to provide a bunch of ViewModel helper for all this state. For example we should have a SelectedViewModel that will intercept only the "selected" property and emit an event on the instanciated SelectedViewModel when a child of that ViewModel is selected (With that child model has parameter). This way, if you want to listen on selected event, you just add this event handler once.

As for change in select policy for example, if we provide a SelectedViewModel, this is where the policy should be applied in my opinion and the top class should be the one having those property. ListView and any inheriting View should be cleared of all of that complexity.

so the view model(proxy) is also in our plan and final structure of efl.ui.view is connected by view model not model right?

ViewModel and Model have exactly the same API. That's why we call it a proxy. There is no difference from the View point of view on what you connect it to. It only see a Model.

In D4986#84628, @cedric wrote:

I think I missed one core feature in my previous mail and my class diagram both, the view model( proxy?). I'm not sure who is working on it and how it will come.
but basically on my understand about MVVM, view model will give abstract interfaces binding on view side, so select, visible, disable, some common view element which controls by model can be exsit in the proxy level.
This might be confused you cuase my previous opinion about states is on view side...
But yeah, still view can also wrapping this state controls cause they might want to give their own feature of state control( such as select policy or mode ).

My current opinion on ViewModel (proxy) for select, visible and enable state, is that the ListView will probe the model it is being given for this property. If there isn't any property like that on the model, it will automatically insert a ViewModel that handle that information. This way the code of the ListView is always the same and doesn't depend on what the Model provide. Additionnally we need to provide a bunch of ViewModel helper for all this state. For example we should have a SelectedViewModel that will intercept only the "selected" property and emit an event on the instanciated SelectedViewModel when a child of that ViewModel is selected (With that child model has parameter). This way, if you want to listen on selected event, you just add this event handler once.
As for change in select policy for example, if we provide a SelectedViewModel, this is where the policy should be applied in my opinion and the top class should be the one having those property. ListView and any inheriting View should be cleared of all of that complexity.

You know, I'm working on list over few years and novice about MVC, MVP and MVVM patterns, so still hard studing about it but my knowlege is poor yet.
As my understanding, general MVVM patterns ViewModel is supposed to be a intermediary of Model and View, and it should encapsulate Model and binding View-dependent data itself, with provide more convenients commend for view and model side both. though they are driven from the model class and it is just extension of model. I think our purpose of apply MVVM is mostly remove dependancy on data model and view and also given more easy and useful unit test ways without acatual view creation.

Generally WPF or Android and most type of MVVM that I was refered shows very simply applied like below,

new Efl.Model MyModel(parent = p);
new Efl.Ui.ViewModel MyViewModel(parent = p, model.set(Mymode)l);
new Efl.Ui.ListView MyList(parent = p, model.set(MyViewModel));

and in legacy

Efl_Model *MyModel = efl_add(EFL_MODEL_CLASS, p);
Efl_Ui_View_Model *MyViewModel = efl_add(EFL_UI_VIEW_MODEL_CLASS, p, efl_ui_view_model_model_set(efl_added, Mymodel));
Efl.Ui.List_View *MyList = efl_add(EFL_UI_LIST_VIEW_CLASS, p, efl_ui_list_view_model_set(efl_added, MyViewModel));

so when they need to set the model to another view, not directly set MyModel to other view, just set MyViewModel to other view,

new Efl.Ui.GridView MyGrid(parent = p, model = MyViewModel);
Efl.Ui.Grid_View *MyGrid = efl_add(EFL_UI_GRID_VIEW_CLASS, p, efl_ui_grid_view_model_set(efl_added, MyViewModel));

But what you explain about state management looks View directly access to the Model without moderating ViewModel, cause you explain to me View will probe Model and if they don't have view-required properties then apply it to ViewModel.

ViewModel --- View --- Model

Yeah.. probably I misunderstand your words.. but anyway in my thought, the role of probing Model properties about View-required features and creating ViewModel's own property or binding Model's already existing property to VIewModel should done by ViewModel itself in constructor or model_set timing not by View... this looks more natural to me.. if we consider the ViewModel as I independant class, but looks both of you think ViewModel is just another level of model and that's all so named on ProxyModel...
Obviously there are many ways exist to implement MVVM patterns and the code that I refered was just what usally other framework(WPF, Xamarine, Android) supported. we could have almost diffrent ways, but for me current ViewModel is uncleared within your explain, and not really sure our benfit will be fullfilled well.. for me actaully It just looks like MV not MVVM. so that is the role of our ViewModel and what is the benefit of our MVVM pattern? I know my MVC and MVVM understand is very week and also we have some cummunication misunderstandings, so it would be much better to using some sample or psuedocode to remove that communication errors.

so the view model(proxy) is also in our plan and final structure of efl.ui.view is connected by view model not model right?

ViewModel and Model have exactly the same API. That's why we call it a proxy. There is no difference from the View point of view on what you connect it to. It only see a Model.

Generally I prefer the way that I mentioned front, create ViewModel and set the Model to ViewModel and if user want to do some special actions inherit ViewModel class and re-implements their own purposes,
so the View only accept ViewModel as a Model Type and every model need to be encapsulated by ViewModel, then ViewModel should have more additional API level (obiously it should have Model's API).
yeah it is just the way of how you provide MVVM patterns and if in our final result,
View, Model and ViewModel every interface can be well-defined and have some their own roles about MVVM, and also gives benefit about management and unit-test things,
the way is not a important things. Please make it clear and let me know if there are something I misunderstood or more role of VM in our MVVM.

In adition, I think our efl.model lack some vital features.
I expect the model interface provide insert_before/after(at least can insert in middle of existing position), prepend, move(reorder), filter things as a basic level.. and those are really necessary kits to widget implementations.

thank you.

As my understanding, general MVVM patterns ViewModel is supposed to be a intermediary of Model and View, and it should encapsulate Model and binding View-dependent data itself, with provide more convenients commend for view and model side both. though they are driven from the model class and it is just extension of model. I think our purpose of apply MVVM is mostly remove dependancy on data model and view and also given more easy and useful unit test ways without acatual view creation.

Generally WPF or Android and most type of MVVM that I was refered shows very simply applied like below,

Yes, this is what we have in mind. Just think of the ViewModel as the class that transform information for the View. Sometimes no transformation are required, but sometime you may want to compute for example a color depending on the value of a property in the Model. Then that operation needs to be done in the ViewModel. Also in simple case, there is just one Model, but the ViewModel can also fetch information from multiple Model to build the information it want to display.

But what you explain about state management looks View directly access to the Model without moderating ViewModel, cause you explain to me View will probe Model and if they don't have view-required properties then apply it to ViewModel.

ViewModel --- View --- Model

Ah, no. What I meant by that is that the View probe the Model that it is given (For the View, there is no difference between a Model or a ViewModel, they have the same API) and if the Model doesn't have the needed feature, it does add automatically the SelectedViewModel that will proxy all the future access to the Model for the View. That way we do not start to duplicate work in the widget itself. We can be quite smart here, we could when someone register for the selected event on the list itself, only then probe the model and add the SelectedViewModel in between. Not to sure of this technic, but that would make our code simpler and application code simpler.

The goal here is to not have multiple code path in the list to handle all the crazy combinatory idea we have got !

Yeah.. probably I misunderstand your words.. but anyway in my thought, the role of probing Model properties about View-required features and creating ViewModel's own property or binding Model's already existing property to VIewModel should done by ViewModel itself in constructor or model_set timing not by View... this looks more natural to me.. if we consider the ViewModel as I independant class, but looks both of you think ViewModel is just another level of model and that's all so named on ProxyModel...
Obviously there are many ways exist to implement MVVM patterns and the code that I refered was just what usally other framework(WPF, Xamarine, Android) supported. we could have almost diffrent ways, but for me current ViewModel is uncleared within your explain, and not really sure our benfit will be fullfilled well.. for me actaully It just looks like MV not MVVM. so that is the role of our ViewModel and what is the benefit of our MVVM pattern? I know my MVC and MVVM understand is very week and also we have some cummunication misunderstandings, so it would be much better to using some sample or psuedocode to remove that communication errors.

In adition, I think our efl.model lack some vital features.
I expect the model interface provide insert_before/after(at least can insert in middle of existing position), prepend, move(reorder), filter things as a basic level.. and those are really necessary kits to widget implementations.

Fully agree with you on that here. List of feature, I think Model should have include : sort, filter, relative insert and move. The question is how should we do that. For example should we have a SortViewModel that people can chain things with and that would sort content for any Model so that Model don't have to implement that feature ? Or do we have to do it in every Model. I would obviously prefer the former, but it may be tricky. @felipealmeida an opinion on this ?

SanghyeonLee added a comment.EditedJul 13 2017, 12:04 AM

sorry @felipealmeida and @larry , I just checked that the patch was updated in branch, give me a time to check it :)
thanks for updating :)

zmike requested changes to this revision.May 2 2018, 3:54 PM
zmike added a project: efl.

This patch needs rebasing.

This revision now requires changes to proceed.May 2 2018, 3:54 PM

@SanghyeonLee

Please give a feedback whether to keep this patch or not.
I think we already have another way to communicate for this subject.

felipealmeida abandoned this revision.May 12 2018, 8:13 AM

A updated version of this patch was pushed to master already.