Page MenuHomePhabricator

[Protytype] scrollable/collection: add new feature for list view.
Needs ReviewPublic

Authored by eagleeye on Sep 16 2019, 12:45 AM.

Details

Summary

When scrolling is finished, item of list view is aligned at center.

Behavior

  1. Scroll manager send a signal to widget when target of scroll position is calculated.
  2. Widget calculates position again, and efl_ui_scrollable_scroll() API is called.

Please give me some feedback.

@prototype

Test Plan

elementary_test -> Efl.Ui.Collection_List

Diff Detail

Repository
rEFL core/efl
Branch
master
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 13313
Build 9407: arc lint + arc unit
eagleeye created this revision.Sep 16 2019, 12:45 AM

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/

eagleeye requested review of this revision.Sep 16 2019, 12:45 AM

the purpose of this patch is
we want to override scroll animation by widget's on demand.

item based widget may want to re-write the scroll feature such as step by items,
or aligning item in viewport position.

we do not want to expose feature specific API set,
so give some common way that easily user/widget can modify as it's on demand.

src/lib/elementary/efl_ui_scroll_manager.c
2445

are this intented fix?
seems it can be raised another ticket.

Do I understand that correctly, you want:

  • Widgets *inside* a scroller, define the animation how the animation is done ?

I am a bit worried about this way of implementing this, as this leads to a really big amount of event and efl_ui_scrollable_scroll spamming, and i feel like there will be definitly some sort of race condition.

Wouldn't it be better to have some special Scroll_Manager that supports specific scroll behaviour ? That would not define any additional API.
Additionally, if the scroll behavior is defined by the widget and not the content, you can also not have some race condition when 2 different widgets in one scroller are fighting for applying their own scroller behaviour.