Page MenuHomePhabricator
Create Task
Maniphest T8115

Provide group feature to PositionManager
Open, HighPublic
Actions

Description

For both Collection and CollectionView we would need to have an ability to have group. In CollectionView, @SanghyeonLee is proposing to have a hierarchy of model so that one level will be group and all the child will be the normal item. This simplify lookup speed for the previous/next Group head. The question is how to expose that information to the PositionManager to get the Group header correct.

Group header are floating, but still accounted in the vertical size of the scrolled item. There is so many way to express the relation between Parent and Children. I am thinking that maybe adding another function callback that return index range for Group would be a solution. Basically you would know that from index i to i + n, they depend on a specific Group and so on. Any idea?

Details

Commits
D9608 / rEFL3cb3c1c4b117: efl_ui_position_manager_grid: start to honor group items
D9586 / rEFLe2b859bdaeab: efl_ui_position_manager: pass on information about group ids
D9587 / rEFL5ad686bc85d4: efl_ui_position_manager_list: make it handle group items
D9583 / rEFL3ce3b3d48ca8: introduce group item
D9582 / rEFL2dfc69397bb1: efl_ui_default_item: remove item parts
D9629 / rEFL185659669837: introduce default item

Related Objects
Search...

cedric created this task.Tue, Aug 6, 8:49 AM
cedric triaged this task as High priority.
bu5hm4n added a comment.Wed, Aug 7, 12:31 AM

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.

cedric added a comment.EditedWed, Aug 7, 9:37 AM
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 😶

SanghyeonLee added a comment.Thu, Aug 8, 12:21 AM

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

bu5hm4n added a comment.Fri, Aug 16, 10:34 PM

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

bu5hm4n added a comment.Sun, Aug 18, 3:58 AM

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)