With the new infrastructure for MVVM, we have a chance to cleanup genlist implementation by basically rewriting it from scratch and providing group, tree, list and grid with fully asynchronous request from the beginning. The remaining question will be own can we have sizing effect on each item (think list in a rounded watch display: https://www.youtube.com/watch?v=2VTBkOVhRwM at 1.33min). It is currently done using a proxy object that hijack the real content of the widget.
Description
Status | Assigned | Task | ||
---|---|---|---|---|
Resolved | felipealmeida | T5355 Replacement of genlist for MVVM | ||
Open | None | T5356 Refactor fileselector | ||
Open | felipealmeida | T7603 Tree View Implementation | ||
Open | SanghyeonLee | T7607 List View Example / Elementary Test Implemenation | ||
Open | SanghyeonLee | T7602 Grid View Implementation | ||
Open | SanghyeonLee | T7608 Grid View Example / Elementary Test Implemenation | ||
Open | bu5hm4n | T8041 RFC Efl.Ui.Item_Position_Manager | ||
Resolved | bu5hm4n | T8115 Provide group feature to PositionManager | ||
Open | bu5hm4n | T8126 Long term extention for Position_Manager |
Global idea for weird layout (like watch circling list or bumping list) is to inherit from the Efl.Ui.ListView and reimplement the layout function.
Thinking on this as I start working on cleaning Efl.Ui.ListView. My idea is to go in the following direction :
- Add an Efl.Ui.InfiniteView class that provide:
- Manage scroller
- Handle factory, realize items and unrealize items that are to much out of the viewport
- Call the Layouter function when any of the visible items size change or the scroller has been scrolled
- Add an Efl.Ui.Layouter interface that provide:
- A function that layout a given set of realized items and request more items if there isn't enough
- Add an Efl.Ui.ListLayouter that inherit from Efl.Ui.Layouter and provide a List Layout
- Add an Efl.Ui.ListView (helper class) that inherit from Efl.Ui.InfiniteView and set at construction the layouter to Efl.Ui.ListLayouter along with some general helper specific to a list
- Add an Efl.Ui.Layouter interface that provide:
- A function that layout a given set of realized items and request more items if there isn't enough
I think it would be important to note here that this function should not depend on anything from Efl.Model, i think it would be super cool if we can reuse those layouters for normal widgets like a simple item_container.
Fully agreed. The size calculation of the item and its monitoring is the duty of InfiniteView which should allow for reusing the Layouter in other type container.
On that same note, the caching and efficient scheduling of the computation is also the job of the InfiniteView.
I'm throwing a yellow card here. If anyone ever names something layouter I will actually explode.
Besides "Layouter" which I agree we should not use, I also don't like "Infinite". Regular list widgets are also potentially infinite so this word has very little meaning.
When looking for a name I think we should focus on the fact that this list is backed by MVVM instead of a regular list container.
And since probably there'll be other widgets backed by MVVM, the naming should be consistent.
Now, I'm not familiar enough with MVVM to suggest meaningful names, but I'll do it anyway to quickstart the brainstorming: Model_List, Database_List, DB_List, On_Demand_List, Runtime_List, Present_List, Display_List.
Regular list won't ever be able to have as many children as the one using MVVM.
When looking for a name I think we should focus on the fact that this list is backed by MVVM instead of a regular list container.
And since probably there'll be other widgets backed by MVVM, the naming should be consistent.Now, I'm not familiar enough with MVVM to suggest meaningful names, but I'll do it anyway to quickstart the brainstorming: Model_List, Database_List, DB_List, On_Demand_List, Runtime_List, Present_List, Display_List.
The thing is that this is not a List. This is a top level container that can do grid, list, tree, whatever kind of layout you can think of which is why I want to avoid the List here. We will have a Efl.Ui.ListView that use this InfiniteView as an helper.
I was more interested in deciding now the prefix. As you say, later we'll add the List, or the Manager or whatever.
Do you people like the prefixes I propose above? Do they make you think of other (better) prefixes?
The important bit is to have the View suffix as that is what the MVVM nomenclature use.
I'm a bit lost now, are we talking about the name of the widget? I know nothing of MVVM but I expected View to be one of the components?
InfiniteView is a View. Efl.Io.Model, Efl.CompositeModel are Model. Efl.Core.ViewModel is an helper ViewModel. The discussion here is about the List/Grid View part of MVVM and how to organize and name them.