|interface Efl.Ui.Scrollbar @beta |├ (P) bar_mode |├ (P) bar_size |├ (P) bar_position |├ (M) bar_visibility_update :: @protected @beta |├ (E) bar,press |├ (E) bar,unpress |├ (E) bar,drag |├ (E) bar,size,changed |├ (E) bar,pos,changed |├ (E) bar,show |├ (E) bar,hide
Description
Description
Details
Details
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Resolved | bu5hm4n | T8096 efl.ui.collection | ||
| Resolved | None | T7870 efl.ui.grid | ||
| Resolved | None | T7881 efl.ui.list | ||
| Resolved | cedric | T7885 efl.ui.list_view | ||
| Resolved | None | T7891 efl.ui.scroller | ||
| Resolved | zmike | T7884 efl.ui.scrollbar | ||
| Resolved | None | T7923 enum Efl.Ui.Scrollbar_Mode | ||
| Resolved | zmike | T7924 enum Efl.Ui.Scrollbar_Direction |
Comment Actions
I think this interface should use the Efl.Ui.Layout_Orientable interface and remove its own enum for horizontal/vertical.
Comment Actions
I am not sure we can use the interface. The users of this interface already use this interface. But maybe we can just change the property bar_mode to use the same data type ?
Comment Actions
I am not sure we can use the interface. The users of this interface already use this interface.
Sorry, what?
Comment Actions
- Event names should be in the past tense.
- Docs need work. Just tell me if each of these is correct and I'll update them.
- bar_size: 0 means bar is invisible, 1 means bar is as big as the widget and cannot move.
- bar_position: 0 means the top of the thumb (the draggable part) is touching the top of the widget, 1 means the bottom of the thumb is touching the bottom of the widget.
The rest of the API seems OK, but I have no knowledge of its internals.
As a user I don't care about scrollbars, because they are something that happen automatically after I set sizes to widgets. Therefore I don't think this API is interesting to users.
As a widget developer, sort of the same, unless I am developing widget with special scrollbar requirements (for example?)
Comment Actions
Right
- Docs need work. Just tell me if each of these is correct and I'll update them.
- bar_size: 0 means bar is invisible, 1 means bar is as big as the widget and cannot move.
Yes, but this also needs to specify that this method "returns the size that the bar should be for the given scroll implementation" or similar to avoid the confusion that we had earlier.
- bar_position: 0 means the top of the thumb (the draggable part) is touching the top of the widget, 1 means the bottom of the thumb is touching the bottom of the widget.
This description assumes vertical orientation, but we have horizontal too...
The rest of the API seems OK, but I have no knowledge of its internals.
As a user I don't care about scrollbars, because they are something that happen automatically after I set sizes to widgets. Therefore I don't think this API is interesting to users.
As a widget developer, sort of the same, unless I am developing widget with special scrollbar requirements (for example?)
You mean like CollectionView?
@woohyun do you need this urgently for creating widgets?
Comment Actions
Yeah, those above were guidelines. I'll take our chat into account, and the different orientations too, obviously.
You mean like CollectionView?
I really don't know, I can't think of any reason why a widget would need to mess with scrollbars at all unless he wants to draw them himself.
Comment Actions
Right, and I'm saying CollectionView does that. So possibly other widgets might need to as well.
Comment Actions
I added patch, https://phab.enlightenment.org/D10040
- Docs need work. Just tell me if each of these is correct and I'll update them.
- bar_size: 0 means bar is invisible, 1 means bar is as big as the widget and cannot move.
- bar_position: 0 means the top of the thumb (the draggable part) is touching the top of the widget, 1 means the bottom of the thumb is touching the bottom of the widget. The rest of the API seems OK, but I have no knowledge of its internals. As a user I don't care about scrollbars, because they are something that happen automatically after I set sizes to widgets. Therefore I don't think this API is interesting to users. As a widget developer, sort of the same, unless I am developing widget with special scrollbar requirements (for example?)
Actually user don't care about scrollbar now, but scrollable widget (such as efl.ui.scroller, efl.ui.collection_list) want to know their scrollbar size and position.
In addition, user want to change bar_mode.
Comment Actions
As @eagleeye told, @bar_mode and bar relating events have been used by lots of applications in Tizen.
So, I hope this interface would be opened if there is no serious problem.
Comment Actions
With the documentation updates and renames that have gone in, this seems pretty reasonable.