A big portion of scrollable interface should be internal and properly refactorized with all our use of it.
Description
Status | Assigned | Task | ||
---|---|---|---|---|
Open | None | T7142 efl 2.0 considerations | ||
Open | cedric | T5301 Make EFL easier to use by improving its interface | ||
Open | eagleeye | T5319 Refactor scrollable mixin |
We(@eunue @eagleeye) are under discussion about "scrollable things".
We made a little humble proposal of those things so that I'm posting here.
Key points of the proposal are like below.
- interface which is a minimal subset of scrollable things
- minimal concrete class which implements the interface
- do not use inherit to make scrollable widgets, but have concrete class
- clear separation between 'scroll' and 'content'
I'm not sure that this concept is feasible and suitable on EFL so that I need your opinion.
Thanks
Should each property in Elm.Interface_Scrollable be a part of Efl.Ui.Scrollable interface?
Property name | YES or NO | Description |
content | NO | Setter only. This should remain internal. |
content_size | NO | Getter only. This simply returns the geometry of the content object. Is not a property of scrollable widgets. |
content_viewport_geometry | NO | Getter only. Pan object’s geometry. This should remain internal. |
objects | NO | This should remain internal. |
extern_pan | NO | This should remain internal. |
gravity | YES | Active when the size of the content or pan changes dynamically. Need to change name? |
policy | YES | Is a property for every scrollable widgets. Need to change name => “scrollbar_mode”? |
single_direction | NO | Is not a property of every scrollable widgets. Widgets except elm_scroller don’t need this. Or do they…? Most of scrollable widgets are one direction. |
loop | NO | Is not a property of every scrollable widgets. Widgets except elm_scroller don’t need this. |
wheel_disabled | NO | This is not subject to API control. Should be part of the configuration. |
bounce_allow | TBD | edge_effect? |
bounce_animator_disabled | NO | |
momentum_animator_disabled | NO | |
movement_block | TBD | These properties should be considered with the properties in elm_widget. |
freeze | TBD | |
hold | TBD | |
repeat_events | TBD | |
step_size | TBD | Maybe only for elm_scroller? Configuration? |
content_region | YES | “content_region” is meaningless. => “content_position” |
mirrored | NO | This is widget property. |
page_size | TBD | See step_size. |
page_scroll_limit | TBD | |
page_snap_allow | TBD | |
paging | TBD | |
last_page | TBD | |
current_page | TBD | |
page_relative | TBD |
I am sadly not really versed in the scroller interface and its use. I am just wondering if we want to make effect part of its API (gravity, bounce and so on) or if there shouldn't be a way to expand the behavior and enable animation some how maybe by a delegated class ? Something that would interact with the animation framework maybe ? I am throwing idea here, nothing else. Let me know what you think.
Each scrollable widget has "Efl.Ui.Scroll.Manager" instance, "Efl.Ui.Scroll.Manager" implements "Efl.Ui.Scrollable".
enum Efl.Ui.Scroll.Single_Direction
{
none = 0, [[Scroll every direction]] soft, [[Scroll single direction if the direction is certain]] hard, [[Scroll only single direction]] last [[Sentinel value to indicate last enum field during iteration]]
}
interface Efl.Ui.Scrollable ()
{
[[Efl UI scrollable interface]] event_prefix: efl_ui; methods { @property content_pos { [[The content position]] set { } get { } values { x: int; y: int; } } @property content_size { [[The content size]] get { } values { w: int; h: int; } } @property viewport_geometry { [[The viewport geometry]] get { } values { x: int; y: int; w: int; h: int; } } @property single_direction { set { } get { } values { single_dir: Efl.Ui.Scroll.Single_Direction; [[The single direction scroll policy]] } } @property bounce_allow { [[Bouncing behavior]] set { } get { } values { horiz: bool; [[Horizontal bounce policy.]] vert: bool; [[Vertical bounce policy.]] } } @property freeze { [[Freeze property]] get { } set { } values { freeze: bool; [[$true if freeze, $false otherwise]] } } @property hold { [[Hold property]] get { } set { } values { hold: bool; [[$true if hold, $false otherwise]] } } bring_in { params { @in x: int; [[X coordinate of the region]] @in y: int; [[Y coordinate of the region]] @in w: int; [[Width of the region]] @in h: int; [[Height of the region]] @in time: double; @in type: int; } } show { params { @in x: int; [[X coordinate of the region]] @in y: int; [[Y coordinate of the region]] @in w: int; [[Width of the region]] @in h: int; [[Height of the region]] } } } events { scroll,start; scroll; scroll,stop; scroll,up; scroll,down; scroll,left; scroll,right; edge,up; edge,down; edge,left; edge,right; scroll,anim,start; scroll,anim,stop; scroll,drag,start; scroll,drag,stop; }
}
Widget still has 4 unclear methods defined:
/* FIXME: Scroll API. Not sure how those APIs should be exposed with * the new scrollable API. */ scroll_hold_push { [[Push scroll hold]] } scroll_hold_pop { [[Pop scroller hold]] } scroll_freeze_push { [[Push scroller freeze]] } scroll_freeze_pop { [[Pop scroller freeze]] }
I assume the following are acceptable:
@property on_show_region_hook @protected { [[Hook function called when the @.show_region is changed. See also @.show_region. ]] set {} values { func: Efl.Ui.Scrollable_On_Show_Region @nullable; [[Region hook function]] } } @property show_region @protected { [[Region inside the widget to show. See also @.on_show_region_hook. ]] set { [[Request parent scrollers to pan around so that this region of the widget becomes visible. If $force is $true this will trigger scroller changes and the @.on_show_region_hook to be called even if the region is unchanged. ]] values { region: Eina.Rect; [[The region to show.]] force: bool; [[Set to $true to force show even if unchanged.]] } } get { [[Returns the current region to show.]] values { region: Eina.Rect; [[The region to show.]] } } }
scroll_hold_push/pop and scroll_freeze_push/pop are necessary. because slider and entry widget use these APIs.
When slider is dragging by user and slider's parent is scroller, scroller will not be moved. so scroll_freeze_push/pop is used.
So I add patch, https://phab.enlightenment.org/D5796
Yes those APIs are necessary, but they are still "not clean" in Efl.Ui.Widget, see T5363. They must be well documented, and it must be clear whether they should be in Widget or only in the Scrollable interface.