This task depend on T5354

See D4986

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

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.

In T5355#137865, @bu5hm4n wrote:

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

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.

In T5355#137883, @segfaultxavi wrote:

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.

I think this can be merged into T8177?