Summary:
Main purpose of exposing widget actions and keyboard shortcuts
is to allow accessibility clients to implement alternative methods
of GUI navigation.
Reviewers: z.kosinski
Reviewed By: z.kosinski
Subscribers: seoz
Differential Revision: https://phab.enlightenment.org/D1227
Summary: When item looping feature is on and press up or down key, screen seems to be frozen.
Test Plan: elementary_test -to "genlist focus" -> click item looing enable -> move list up and down
Reviewers: anand.km, seoz, woohyun
Subscribers: singh.amitesh
Differential Revision: https://phab.enlightenment.org/D1193
Summary: First item of widget should be focused when focus comes to the widget for first time.
Test Plan:
elementary_test -to "Genlist Focus"
elementary_test -to "Gengrid Focus"
elementary_test -to "List Focus"
elementary_test -to "toolbar Focus"
Reviewers: seoz
Differential Revision: https://phab.enlightenment.org/D1135
in current code, when a list item is selected, "selected" callback is called first
and then focus is set to the item. this is a problem if another widget, popup for instance,
is created on top of the list in the callback function. in such a case, the popup should
get focused (not the list item). this patch fixes it by changing the order.
@fix
Summary:
If focus is set on item content object, it's treated as a
different object which results the focus deadlock. So, every
time whenever focus sets on item content object, we need to
unset and set the focus on genlist object. Thanks to Seoz for
the idea.
Test Plan: elementary_test -to "list focus"
Reviewers: seoz, SanghyeonLee, eagleeye
CC: seoz
Differential Revision: https://phab.enlightenment.org/D973
Summary:
Upon focus set, if the item content object is not of type widget
(could be of type Evas_Rectnagle) focus set/get is not possible.
ERR<17428>:eo lib/eo/eo.c:603 _eo_call_resolve() in elm_widget.eo.c:112: you called func 'elm_obj_widget_can_focus_get' (239) which is unknown in class 'Evas_Rectangle'.
ERR<17428>:eo lib/eo/eo.c:788 _eo_api_op_id_get() in elm_widget.eo.c:212: unable to resolve regular api func 'elm_obj_widget_child_can_focus_get' 0xb75e6f40 in class 'Evas_Rectangle'
Test Plan: elementary_test -to "list focus" (make focus_on_selection enabled and give a right key event when a content object is focused)
Reviewers: seoz, SanghyeonLee, eagleeye
CC: seoz
Differential Revision: https://phab.enlightenment.org/D972
Reset the last_focused_item on _item_focus_set_hook.
This fixes the issue which sets the focus to the wrong item when the
focus is set by an API.
Reproduction step:
elementary_test -> genlist focus -> click an item (not the 2nd item) -> click "Focus 2nd
Item after 1.5 seconds" button.
Focus is not moved to the 2nd item.
@fix
elm_config_focus_auto_scroll_bring_in_enabled_get/set()
->
elm_config_focus_autoscroll_mode_get/set()
The main reason is that bring_in_enabled_get/set() APIs are too restricted
and thus not flexible. I got more requirements for the focus autoscrolling
such as none, wholely visible not just bring_in and show. So it is correct
to add mode_set/get() APIs for the focus auto scrolling.
Thanks god, we've found this before the release :)
@feature
This reverts commit 377179bdaf84aa1a86621cdfa64ed43613ab9d45.
The main claim of https://phab.enlightenment.org/T1205 was fixed in
the previous commit 30cada369. This code will be modifed again in the
next commit due to the api change during development life cycle.
Note: do not blindly revert this commit if you have any problem with
widget item focus. This commit is not related to any fundamental cause
of the issues. If you have a problem, please contact me first.
seojuyung2@gmail.com or SeoZ on IRC.
Thanks.
This was introduced during 1.10 development phase but this changed the
default focus behavior and got a lot of complaints. (especially from
discomfitor)
So I would like to comment this out now and make it optional on 1.11
by keeping the default behavior.
Fixing this issue is not trivial and will bring another issues like crashing.
So it is better to fix this in a development phase by refactoring list.
To fix this issue, the following are needed:
1. it->walking concept should be adopted instead of using just sd->walking.
sd->walking was introduced in beb418d6
2. elm_widget_item_del() should be called instead of the combination of
_elm_list_item_free() + elm_widget_item_free()
This was introduced in f343011d
This fixes variable initialize problems related to focus. This can be
reproduced when you enable focus highlight/animation and reuse
elm_list by clearing it.
This problem occurred because list item del pre is never been called.
This bug will be addressed in a next commit.
This reverts commit b8549f3e83a8592145a50085182583adead2c74e.
this build system is bad and whoever did the eo integration should not feel pleased with themselves.
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)
- Added internal function _elm_list_elm_widget_event_direction.
- Simplified cascaded if statements.
- Note: focus_on_selection feature is still broken.
- Moved a check for direction at the start of the function based on the
horizontal mode configuration.
- Removed unnecessary focus set to edje object. In this case, that item
will get the focus automatically by elm widget item focus
infrastructure.
But this focus_on_selection feature is still broken. I need to fix them
more.
Summary:
If item loop feature is enabled, item is moved infinitely.
1. add new widget api - item_loop_enabled
2. add smart event using new config - elm_list.c
3. add demo - test_list.c/list_focus
Reviewers: seoz, woohyun, raster, jaehwan, Hermet
CC: singh.amitesh, c
Differential Revision: https://phab.enlightenment.org/D619
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.
This patch is a list version of genlist patch cc827fef6.
Now, list does not autoscroll to last focused/selected item when the list
is focused. It tries to find the nearest visible item instead of the
last focused/selected item.
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.
Tom Hacohen
Daniel Juyung Seo
Lukasz Stanislawski
Hosang Kim
Anil Kumar Nahak
Jaeun Choi
wonguk.jeong
Amitesh Singh
efl
Zbigniew Kosinski
zmike
Carsten Haitzler
ChunEon Park
Daniel Zaoui