this.is.BROOOOOOOOOOOOOOOKEEEEEEEEEEEEEEEEEEENNNNNNNNNNNNNNNNNNNNNNNNNNNNN.
SERIOUSLY.
you cannot go scrolling all over the place in every widget that has a scroller just because the widget gets focus. what user wants that? no user anywhere, under any circumstances, ever, in all of history.
if you dare to put this back in, I will continue to remove it for the rest of eternity until it never, ever scrolls in any unwanted case. the focused item doesn't have to always be in the viewport, and should never be moved into the viewport [[[[[[[ except to maintain an already-existing position inside the viewport ]]]]]]]
too much of my time wasted on this stupid "feature" which should have been MUCH more thoroughly tested and reviewed before it was merged.
T1205 STILL NOT FIXED
First on_focus call should consider focus highlight enable status and
do the different job according to that.
This can be tested in "genlist 7" and "genlist focus" examples in
elementary_test.
Summary:
Issue: As entire scroller edje co-ordinates was being taken instead of the actual viewport value,
if in scroller edje more parts are added apart from just "elm.swallow.content", then the viewport value
set will be wrong. hence the selection handlers will not hide when they have to hide.
solution: Instead of taking scroller edje's geometry, get the actual viewport values.
To get viewport x,y a new scrollable interface is also added.
signed-off by: Shilpa Singh <shilpa.singh@samsung.com>
@fix
Test Plan: Selection handlers have to hide correctly when the text is scrolled in a scrolled entry, if the scroller edc of entry has more parts added other than elm.swallow.content, then when we scroll the selection handlers are not hidden correctly.
Reviewers: jaehwan, woohyun, seoz, Hermet, raster
CC: govi, rajeshps, thiepha
Differential Revision: https://phab.enlightenment.org/D674
we can prevent to handle the widget events from the widget infra,
if the object is disabled.
conceptually, disabled object should not be interacted to user input(key, mouse)
codes.
- Added a check for focus highlight enable status before calling focus
signal to edje.
- Used obj instead of WIDGET(it) because that is used many times.
On smart_on_focus, genlist calls elm_object_item_focus_set. That API
internally calls _elm_widget_focus_highlight_start() but we need to call
this function once again because of the weird focus behavior.
Condition: enable focus highlight and focus highlight animation.
The first _elm_widget_focus_highlight_start() triggers
_elm_win_focus_highlight_simple_setup, and second call triggers
_elm_win_focus_highlight_anim_setup. But the first call does not show
the focus highlight object properly.
Reproduction scenario:
1. elementary_test -> genlist focus
2. click an item
3. scroll the genlist and move the focused item away from the viewport.
4. move the mouse pointer to another window
5. move the mouse pointer to the genlist window back again.
6. focus highlight object is now shown correctly.
By the way, this bug will be hidden when the focus highlight never
scrolls away. I will add this feature soon.
event.
When you use mouse(touch) that triggers mouse up event, the
focus/selection movement is done by mouse up callback, so don't need to
handle on_focus event when mouse(touch) is used.
You can reproduce the bug by the following step.
1. launch elementary_test -> list focus, genlist focus, gengrid focus
2. focus an item (by touch, by key)
3. move focus to left button (by touch, by key)
4. click an another item (by touch)
5. previously focused item will be unfocused again even it was unfocused
at step #3/
Special thanks to Amitesh for the report.
Now it works so much better than before.
- Fixed the separate behavior between selected item and focused item.
- Fixed wrong focus set when genlist is focused first time by mouse.
- Fixed wrong scroll movement when the focus highlight is disabled.
- Item selection sets that item focused. So when an item is selected, do
not need to set the focus again.
- Fixed wrong call for _elm_genlist_item_content_focus_set on deleted
item.
Now, genlist does not autoscroll to last focused/selected item when the genlist
is focused. It tries to find the nearest visible item instead of the
last focused/selected item.
Due to Eolian auto-generation, legacy parameters are directly
transferred to Eo functions without conversion.
In this case, is_next was Eina_Bool in legacy and Eina_Bool * in Eo.
The logic code was expecting a pointer but was receiving a Eina_Bool.
The fix consists in giving the logic code the Eina_Bool instead of the
pointer.
@fix
- Changed wrong name alpha_bg to event_block_rect.
- Added more comments to the smart data variable.
- Changed wrong function name _tray_alpha_bg_create to
_event_block_rect_update.
Added one more internal variable to reduce unnecessary pointer
redirection too much.
Elm_Genlist_Smart_Data *sd is used many times in those functions but it
was always redirected from psd->wsd. I just cut down the step and made
the code more readable and consistent with other lines of code.
psd->wsd --> sd
Summary:
Implemented the following function
1. _item_unfocused
2. _item_focused
3. _item_focus_up
4. _item_focus_down
5. _item_focus_left : Currently this function return EINA_FALSE. It means focus will move out of genlist to the another left widget
6. _item_focus_right : Currently this function return EINA_FALSE. It means focus will move out of genlist to the right widget
7. _item_focus_set_hook
8. _item_focus_get_hook
9. _elm_genlist_focus_highlight_geometry_get
10. _elm_genlist_focused_item_get
11. Changes in the smart_event, smart_on_focus, pan_smart_calculate, mouse up callback.
Currently selected/focus logic are both present in the smart_event function and its
will be separate out.
Reviewers: seoz, woohyun
CC: singh.amitesh
Differential Revision: https://phab.enlightenment.org/D558
Conflicts:
src/lib/elm_genlist.c
_list/genlist_item_focus_set --> _list/genlist_item_content_focus_set.
These internal functions set the focus to the item's content objects,
not the item itself. So the name was wrong and very confusing.