Rebasing

Optimized usage of list iterator

Please find my comments

In D9214#170003, @zmike wrote:

This needs some work and more testing. I've created an example unit test for this functionality; please add another test to verify the exact issue that you are trying to resolve.

Updating with the content of duplicate diff D9248, some code review changes also included

@SanghyeonLee Any changes needed for this patch? Should we mark item for update even in text update? Only in case of multiline text items we may have to do item update on a text update

In D5428#94545, @raster wrote:

well i see it as a bug. what you might do is come up with a way of having "empty blocks" that have not been filled in/realized yet and padthese between start and "item show" point.

@raster
With empty blocks also, as we won't be able to know the block size before processing items in block, we may end up with pan object size changes during processing of items in queue.
One working solution which I found is pausing processing of items in queue when a user scroll happens so that pan object size and position will not be disturbed and then resume processing when user stops scrolling. But I am not sure whether it is acceptable.

@raster
Yes. This is a known limitation with this approach and I was trying some solutions to handle this. As we are not processing items in proper top to down order, and items are getting filled to both top & bottom directions of list from the show item position, So when user is scrolling, the anchor item logic cannot hold and as pan object height is changing, scroll position jumps are happening. I will update patch once some good solution on this is done.

Block processing improved

Adding test case to prepend items while genlist queue is processing

Improving the scroll deferring logics and scrolling when item cannot be scrolled to scroll_to position

Focused item get API will be valid only when ctxpopup holds items,
If there is no items then this API don't have to handle anything.

@raster Yes, I'm making test cases for all scenarios and that is how I was able to find those issues, Was not sure whether to push all the scenarios to elementary test, However I will try to cover all the scenarios with the changes and will update elementary test too. Thanks for the review.

Fixes for processing items with relatives

Removing unwanted changes

Deffering scroll till genlist takes a height to support ELM_GENLIST_SCROLLTO_MIDDLE

In D5428#92899, @SanghyeonLee wrote:

The idea is actually I have been discussed with hyuksoon choi, but when I applied it in our tizen,
It gave lots of bugs so I abandoned it. I guess there were some mistake of mine, so I hope this one working well.let me check about it.
Thanks to apply this feature :)

In D5428#92926, @raster wrote:

how do you ensure the item stays in the viewport? do you keep moving the scroller viewport/position around as you calculate items before.after the show item?

In D5428#92922, @raster wrote:

but how do you know WHERE the "show item" is without knowing the size od all items before it? imagine a list of 10,000 items. and you want to show item 9,900. you dont know where to jump to because you need all the 9899 before it to be calculated ... ? you dont know where the block is because you dont knwo the size of prior blocks.... :/

In T6263#104087, @jpeg wrote:

Do we really want that many new features in genlist? Genlist is so damn complex and full of bugs already :(
Not saying the feature isn't good, or the patch either, just saying that the maintenance cost needs to not grow too much :)

In D5428#92578, @raster wrote:

only if the list is homogenous does genlist know the size of a block... in the case it is not... what is the point of assigning items to blocks when size is still unknown?

In D5340#91743, @SanghyeonLee wrote:

Yeah but just for make sure about it,
could you please re-commit with changing commit msg or few line gaps?
then we could check jenkins build result once again. I think there should be no-problem..

Re-commit for jenkins build check

In D5340#91623, @SanghyeonLee wrote:

Is it finished all?
I don't know why jenkins got build failed message, but its working well in my local.

@jpeg In a list with group items, There will be no stacking above in Z direction, always it will be placed below (Y Direction).
if the group item (parent) of pinned item is realized, the pin item will stay below its group item.
Other group items (non parent of the pinned item) when reaches above the screen, pin item will remain on top of the list and group items will stay below the pin item (Y Direction)

Handling pin item deletion

@SanghyeonLee This concept works with cases which have group index items too in the list,
You can check elementary_test->Genlist Group -> Double click item

Yes, This feature was implemented in patch through item class callbacks,
https://phab.enlightenment.org/D3669?id=8397
Later as item class callbacks could not be changed, updated the patch only for emitting signals.

@SanghyeonLee
Yes, There can be cases as below (top left item is focused but not fully in viewport),
So if I click that item it won't be scrolled in which I felt as not normal from a user point of view.

Updated patch, In any list mode item width should not be less than
viewport width.

Removed item class callbacks and implemented only events for now

Removed item class callbacks and implemented only events for now

This patch is already commited with the commit 6785fa01252f0b789d6c93ee6f52afcda4a3aa7a
How to close this?!

• Fixed comment

• Removed unwanted changes

• Removed unwanted changes

D3567

Rather than changing horizontal hoversel like this, it will be better to add feature
to set direction priority in vertical hoversel if we want to have a hoversel like this right?
Similiar to the behaviour of direction priority set of ctxpopup.

• Added @since tag

• Added @since tag

That is a different issue, In hover only the swallow part is animated and the button_image part which is not animated remains on screen till the hover object is hidden. It will be hidden once the hide,finished signal is received. If required I will raise another patch to handle that issue.