Page MenuHomePhabricator

Replacement of genlist for MVVM
Open, HighPublic

Description

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.

cedric added a comment.Apr 4 2017, 3:34 PM

This task depend on T5354

cedric raised the priority of this task from TODO to High.Jul 10 2017, 2:42 PM

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.

zmike edited projects, added Restricted Project; removed efl.Jun 11 2018, 6:54 AM
zmike edited projects, added efl: widgets; removed Restricted Project.Jun 11 2018, 8:15 AM
zmike added a subscriber: zmike.

A #Goal ticket should not be set to a milestone.

zmike edited projects, added efl: mvvm, efl (efl-1.22); removed Restricted Project.Jan 9 2019, 12:09 PM

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.

  • 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.

zmike added a comment.Jun 27 2019, 5:11 AM

I'm throwing a yellow card here. If anyone ever names something layouter I will actually explode.

Position_Manager ? Positioner ? Active_Positioner ?

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.

In T5355#137880, @zmike wrote:

I'm throwing a yellow card here. If anyone ever names something layouter I will actually explode.

I am bad at naming. My second choice was bob. Not sure it is any better.

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.

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.