Page MenuHomePhabricator

Naming our collection container
Closed, ResolvedPublic


We do have a series of widget that are going to have symmetric behavior for holding large quantity of object in a viewport with a scroller. For that purpose @bu5hm4n has started to refactor things into Efl.Ui.Item_Container. The logical outcome of this is that we would have :

  • Efl.Ui.Item_Container
  • Efl.Ui.Item_List
  • Efl.Ui.Item_Grid
  • Efl.Ui.Item_Position_Manager

And for the MVVM bits:

  • Efl.Ui.Item_Container_View
  • Efl.Ui.Item_List_View
  • Efl.Ui.Item_Grid_View

Pretty terrible. We could use Efl.Ui.Container (We do have a Efl.Container, but it is not a widget) or Efl.Ui.Collection (as a Collection implicitly contain items). Collection is more often used in other system to describe a widget that has a scroller and hold multiple other widget. So I would propose to go with the following:

  • Efl.Ui.Collection
  • Efl.Ui.List
  • Efl.Ui.Grid
  • Efl.Ui.Position_Manager

And for the MVVM bits:

  • Efl.Ui.Collection_View
  • Efl.Ui.List_View
  • Efl.Ui.Grid_View

Related Objects


Yeah...that was ugly.
I prefer this collection naming,
but only concern is collectionView is used in other framework as actual collection shelf view.
yet I think it is doable name till we have other good candidate.

Mhm, a few things:

  1. this ticket leaves out a few essential classes, we bring a few Position_Manager implementations with us, which would then also be placed in the Efl.Ui namespace, which is something i do not like, they should be hidden in some namespace IMO.
  2. I also do not prefer to have a specific class Efl.Ui.List & Efl.Ui.Grid. The difference between List and grid is a call in the constructor, i think we could either add an utiliy class for that, or let the user create it themselfs.
  3. Collection is way too general, from a mathemetical POV, a box, table, spotlight layout is nothing else than just a Collection, so i think its rather hard to see the difference to the other widgets based on this name.

Hmmm... I DO like that the user can see Efl.Ui.List and Efl.Ui.Grid and knows NOTHING about the container and view manager classes. This is what other toolkits do.
Of course, our structure is awesome and allows for other arrangements to be created just by adding a new view manager, but I don't think standard users will care about this.
So, why don't we create a namespace and put there the container and view managers, but leave outside the plain List and Grid widgets?
In this way, the name we choose is sort of private (in the sense that most users will never need to use it).

To summarize, I propose:

  • Efl.Ui.Item_Container: Namespace (Name pending)
  • Efl.Ui.Item_Container.Container
  • Efl.Ui.Item_Container.Position_Manager
  • Efl.Ui.Item_Container.List_Position_Manager
  • Efl.Ui.Item_Container.Grid_Position_Manager
  • Efl.Ui.List: Just a constructor instantiating the appropriate container and manager.
  • Efl.Ui.Grid: Idem.
  1. For the additional class I am thinking of the following :
    • Efl.Ui.Position_Manager.Entity
    • Efl.Ui.Position_Manager.List
    • Efl.Ui.Position_Manager.Grid
  1. I agree with @segfaultxavi, every toolkit provide a Grid and a List and user expect them as a base class. So at the end our main namespace would have :
    • Efl.Ui.List
    • Efl.Ui.Grid
    • Efl.Ui.Collection
    • Efl.Ui.ListView
    • Efl.Ui.GridView
    • Efl.Ui.CollectionView
  1. Collection is actually a term used in many toolkit to describe exactly what you are naming Item_Container. As a quick search, I did ios collection and got this as the first link: . Sure that Android, react and friends have the same.

Okay, i am convinced. I like that.

cedric closed this task as Resolved.Jul 24 2019, 10:50 AM
cedric reopened this task as Open.Jul 24 2019, 10:55 AM
bu5hm4n closed this task as Resolved.Aug 5 2019, 10:09 AM

I think this is done ?