It seems that this patch has no reviewers specified. If you are unsure who can review your patch, please check this wiki page and see if anyone can be added: https://phab.enlightenment.org/w/maintainers_reviewers/

about the grid... content_item can be useful, but default item, they might need different visualization in grid actaully.
the idea you told me can reduce the useless repeatation of item classes, so in some ways, I agreed.
we can go the common item styles,
Efl.Ui.Default_Item
Efl.Ui.Content_Item
Efl.Ui.Title_Item
(note: we cannot go with "View" term cause it still used in Efl.Ui.List and Efl.Ui.Grid)
but I think internally they might checking who is my parent class and find different edje styles based on parent class, like,
efl/list_item:default
efl/grid_item:default
efl/tree_item:default
in the edc styles.

after this dicussion,
i'll abandon this patch and recreate / split new patches with

rename empty_item to content_item(is this name okay?)
rename list_item to item
efl_part implements in item
add label part in default_item

hmm but still there are some doubt about idea...
what if we need different efl_part in different parent classes?
I think we still need list_item and grid_item for these cases,
and I'm agreed with combined item class for what we can provide.
same style name, same part properties..

To provide my input I need to understand what is going on here.
If anybody has the time, can you explain how all these classes are used? What are the empty and default items?

In D7474#136789, @SanghyeonLee wrote:

about the grid... content_item can be useful, but default item, they might need different visualization in grid actaully.
the idea you told me can reduce the useless repeatation of item classes, so in some ways, I agreed.
we can go the common item styles,
Efl.Ui.Default_Item
Efl.Ui.Content_Item
Efl.Ui.Title_Item
(note: we cannot go with "View" term cause it still used in Efl.Ui.List and Efl.Ui.Grid)
but I think internally they might checking who is my parent class and find different edje styles based on parent class, like,
efl/list_item:default
efl/grid_item:default
efl/tree_item:default
in the edc styles.

I very much like the idea of relying on the parent class at creation time to define the edc style. Still it might be tricky to manage to do that as the style is provided by the model and the model doesn't see the parent class. We could have a dedicated model for each type of View that generate the proper style information. If you have an idea on how to implement this, I will love it as I really think having a limited amount of item class would be best.

after this dicussion,
i'll abandon this patch and recreate / split new patches with

Could you use git phab in the future? It is easier to work on bigger series of patch with it.

rename empty_item to content_item(is this name okay?)

This is one of the item that really look like it could be generic for all view. What about efl.ui.view.content_item? For @segfaultxavi, the style of this item is completely neutral, no decoration and can only contain one object inside it.

rename list_item to item

I have a preference for the namespace efl.ui.view.*_item for as much as possible that can be made generic.

efl_part implements in item
add label part in default_item

Sounds good.

In D7474#137013, @segfaultxavi wrote:

To provide my input I need to understand what is going on here.
If anybody has the time, can you explain how all these classes are used? What are the empty and default items?

Will try. Basically List_View, Tree_View and Grid_View need items to display information. Those item in efl world are themed by edje and are some child of Efl.Ui.Layout logically. So they have part, some even have slot that can swallow content. The View will ask the Factory by providing the Model that match a specific Item position to create the visual object that is somekind of Efl.Ui.Layout. To specialize this Item and make life for developer easier, we are providing a set of base Item class that have a known set of label and swallow/part. This is what this *item*.eo are.

empty is an item class that has only one unique swallow. The advantage over just creating a Widget from the Factory in this case is that the developer/system can provide a custom theme that will define margin, background and other visual effect to look uniform on all cell inside a View.
default is an item class that has an icon (maybe two, I don't remember) and a label if I remember correctly. It is the most expected item for any View, I would say (But as @SanghyeonLee pointed out, the layout might change depending on which View it is used. For example in a grid, it would be stacked, while in a list, it would be side by side).

OK, thanks @cedric for the explanation.

These are my two cents:

• Regarding Empty_Item or Content_Item:
  • I do not like Empty because it looks like it has nothing inside.
  • I do not like Content because all other items have content too, this is not the only one.
  • How about Custom_Item, Customizable_Item or Placeholder_Item?
• Regarding namespaces:
  • I agree that if an item can be used both in a List and in a Grid, it should not be in the List namespace.
  • I also understand that an item might look different when inside a List or when inside a Grid.
  • How about we name the items with a description of their content and put them outside of any particular view? Efl.Ui.View.Default_Linear_Item (contains text and buttons side by side), Efl.Ui.View.Default_Stacked_Item (contains text and buttons on top of each other), Efl.Ui.View.Default_Title_Item (contains only text), Efl.Ui.View.Placeholder_Item (contains only one swallow).

In D7474#137368, @segfaultxavi wrote:

OK, thanks @cedric for the explanation.

These are my two cents:

• Regarding Empty_Item or Content_Item:
  • I do not like Empty because it looks like it has nothing inside.
  • I do not like Content because all other items have content too, this is not the only one.
  • How about Custom_Item, Customizable_Item or Placeholder_Item?

I like both Cutomizable_Item and Placeholder_Item with a slight preference for Placeholder_Item.

• Regarding namespaces:
  • I agree that if an item can be used both in a List and in a Grid, it should not be in the List namespace.
  • I also understand that an item might look different when inside a List or when inside a Grid.
  • How about we name the items with a description of their content and put them outside of any particular view? Efl.Ui.View.Default_Linear_Item (contains text and buttons side by side), Efl.Ui.View.Default_Stacked_Item (contains text and buttons on top of each other), Efl.Ui.View.Default_Title_Item (contains only text), Efl.Ui.View.Placeholder_Item (contains only one swallow).

Sounds good. I will just advocate that if the item could layout depending on there parent, we can go with simpler naming. Like Efl.Ui.View.Default_Item would be an Item that has space for a swallow and a label as a legend. Otherwise the proposed schema is nice as it extend without leaking into another namespace.

In D7474#137211, @cedric wrote:

In D7474#136789, @SanghyeonLee wrote:

about the grid... content_item can be useful, but default item, they might need different visualization in grid actaully.
the idea you told me can reduce the useless repeatation of item classes, so in some ways, I agreed.
we can go the common item styles,
Efl.Ui.Default_Item
Efl.Ui.Content_Item
Efl.Ui.Title_Item
(note: we cannot go with "View" term cause it still used in Efl.Ui.List and Efl.Ui.Grid)
but I think internally they might checking who is my parent class and find different edje styles based on parent class, like,
efl/list_item:default
efl/grid_item:default
efl/tree_item:default
in the edc styles.

I very much like the idea of relying on the parent class at creation time to define the edc style. Still it might be tricky to manage to do that as the style is provided by the model and the model doesn't see the parent class. We could have a dedicated model for each type of View that generate the proper style information. If you have an idea on how to implement this, I will love it as I really think having a limited amount of item class would be best.

after this dicussion,
i'll abandon this patch and recreate / split new patches with

Could you use git phab in the future? It is easier to work on bigger series of patch with it.

rename empty_item to content_item(is this name okay?)

This is one of the item that really look like it could be generic for all view. What about efl.ui.view.content_item? For @segfaultxavi, the style of this item is completely neutral, no decoration and can only contain one object inside it.

I think it need to be Efl.Ui.~ not Efl.Ui.View~ cause it also can be an item of Efl.Ui.List and Efl.Ui.Grid. we still share this class with view and list both cases.

rename list_item to item

I have a preference for the namespace efl.ui.view.*_item for as much as possible that can be made generic.

efl_part implements in item
add label part in default_item

Sounds good.

In D7474#137711, @cedric wrote:

In D7474#137368, @segfaultxavi wrote:

OK, thanks @cedric for the explanation.

These are my two cents:

• Regarding Empty_Item or Content_Item:
  • I do not like Empty because it looks like it has nothing inside.
  • I do not like Content because all other items have content too, this is not the only one.
  • How about Custom_Item, Customizable_Item or Placeholder_Item?

I like both Cutomizable_Item and Placeholder_Item with a slight preference for Placeholder_Item.

honestly my first proposal was custom_item and manual_item before @smohanty point out it sound awkward :p
now I can believe you guys opinion than him now :)
I know why you prefer customizable than custom but it sound to long... what about Decorate_Item?
placeholder is understandable for me, but I'm doubt that it is easy to understand who begins efl.

if you don't think decorate is good enough,
I'll go customizable.

• Regarding namespaces:
  • I agree that if an item can be used both in a List and in a Grid, it should not be in the List namespace.
  • I also understand that an item might look different when inside a List or when inside a Grid.
  • How about we name the items with a description of their content and put them outside of any particular view? Efl.Ui.View.Default_Linear_Item (contains text and buttons side by side), Efl.Ui.View.Default_Stacked_Item (contains text and buttons on top of each other), Efl.Ui.View.Default_Title_Item (contains only text), Efl.Ui.View.Placeholder_Item (contains only one swallow).

Sounds good. I will just advocate that if the item could layout depending on there parent, we can go with simpler naming. Like Efl.Ui.View.Default_Item would be an Item that has space for a swallow and a label as a legend. Otherwise the proposed schema is nice as it extend without leaking into another namespace.

still I'm not sure it need to be Efl.Ui.View_~..
we could go...
Efl.Ui.Default_Layout_Item,
Efl.Ui.Customizable_Layout_Item

I'm not certain which case need other type of items.
in toolbar or pager, naviframes,
make them restrict the type of items for their own series..

icon, endicon and label,
content for customable layout,
sounds quite generic to me, so I could be useful for all other item packable widgets.

If we call it Decorated_Item, then it looks like the other items are not decorated :(
Damn! This is difficult!
The name has to explain that this item has just one swallow, and is decorated just like the rest...
What about Single_Item or Swallow_Item? I do not think Placeholder_Item is bad, and people working on UI should be familiar with the concept.

yeah naming is really difficult thing always :p
though I like the Swallow_Item idea,
but if you two are voted Placeholder, so I'll go with it.