Item side

I think the problem with the item side is that we have a API which allows arbitary position of the items, but the grouping also puts a rule of positioning onto it, feels like a little bit racy. For getting around that we could ensure that in Efl.Ui.Collection we only accept items that are not grouped. After that, we can add API to the group item, for adding items as its children, which are then propagated *somehow* to the Collection. (I am not sure how much this is needed in Collection_View)

Position Manager side

I think we need more information here, can the grouping be recursive, or only 1 level ?
We could adjust the function callbacks to always fill additional information next to the size / object. Like a "special" bit if its a group, and a group_id int for expressing the grouping itself. The group_id then would also be the id of the group-item itself, with that the placement etc. should be able to do. Does that sound good ?

Group Item

This needs to be created first, are there any special requirements, someone with a idea for a theme?

(I am on vacation from tomorrow to the 19.08) I do not think that i can take care of it before coming back.

In T8115#139633, @bu5hm4n wrote:

== Item side ==

I think the problem with the item side is that we have a API which allows arbitary position of the items, but the grouping also puts a rule of positioning onto it, feels like a little bit racy. For getting around that we could ensure that in Efl.Ui.Collection we only accept items that are not grouped. After that, we can add API to the group item, for adding items as its children, which are then propagated *somehow* to the Collection. (I am not sure how much this is needed in Collection_View)

Uh, you want to express the group as part of the item and have an interface that list child on it? My issue would be that in collection view, I never want to have all the children of a group alive at the same time and I will have to constantly insert/remove there. I am not a fan of that idea. I don't think it is actually necessary.

== Position Manager side ==

I think we need more information here, can the grouping be recursive, or only 1 level ?

Only one level. This is not a tree.

We could adjust the function callbacks to always fill additional information next to the size / object. Like a "special" bit if its a group, and a group_id int for expressing the grouping itself. The group_id then would also be the id of the group-item itself, with that the placement etc. should be able to do. Does that sound good ?

I wanted to avoid adding an extra set of byte for each item as it seems very inefficient. That's why I was proposing a range fetch API as that would alleviate any redundancy. Arguably I can live with a few extra byte as they will only be for the current viewport.

== Group Item ==
This needs to be created first, are there any special requirements, someone with a idea for a theme?

Copy what genlist does ?

yes. we can go with current group index.

we have some features that group title floating upon the child item and fallow the scroll on top position,

I hope this feature is become an API that turns on & off.
also we could adding group pad feature for the convenient.

grid title on the vertical scroll would be same as list one,

but on horizontal,
we don't have any group feature yet,
so I suggest this way.

Additionally,
if we make our model with one level child,
like,

model
-groupitemA
--childitem1
--chliditem2
-groupitemB
--childitem1
--childitem2

this group can be the information of index(fastscroll) widget.

but I don't know how to support index without group...

@cedric do you think you will ever be interested in the group item of the first item in the size callback ?

The basics are there. The accessing is still quite rough.

I am wondering if i could take the following assertion:

• If you are accessing the size, you will only be interested in *maybe* the id of group, but mainly the size of the group item.
• If you are accessing the object, you will only be interested in the group object itself, and the id of it.

Additionally, there are 5 "things" about a item that are essential:

1. Its graphical representation (the object itself, not neccessarily physically there)
2. Its size (Needs to be decoupled from 1., object might not be available
3. Its state (I am a group, I am not a group)
4. Self id
5. Group id

I am wondering if we should just pass all those information to the position manager when a new item is added / removed. This would significatly lower the amount of calls to the callback. (It would actually remove all needs of "give me 1 element at id X")

What do you think about this is this applicable for collection_view ? (I would create new revisions for it)