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.
Item selection also sets the focus automatically so do not need to set
focus twice. This code needs to be changed later again when the
selection by key arrow becomes optional.
of highlighted_item.
highlighted_item will be NULL after the first click and it is not
useful. To avoid first item focus -> first item unfocus -> clicked
item focus on the first focus to list widget, this patch is needed.
Thanks for the report Ceolin.
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
On a list that have not received focus yet a mouse down gives the focus
for the list (that gives the focus for the first item) and the mouse
up the item is selected and receive the focus.
The problem: if the list is scrolled the focus given for the
first item makes the list scroll to the top and not for the item
selected by the user.
If the list is deleted/recteated the _elm_list_item_focused/unfocused() is
called and the sd pointer is null.
This unbreak all my apps that use elm_list
With the introduction of the patch 3628a8c4ea2485ee7ee5a81cfd4e0f0fe62b10d6,
it is possible to highlight focused Elm_List and Elm_Genlistenlist items.
However, this feature does not work correctly if one wants to create a custom
highlight theme for Elm_List items.
The whole problem was happening, because the function
_elm_widget_item_highlight_in_theme() was being called in a incorrect
location. This function must be called at _items_fix(), because
there the Elm_List already set the item theme and then it's possible
to check if the one wants a custom highlight or not.
_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.
Summary:
Problem: list theme (elm/list/base/default) is an alias of scroller
base theme (elm/scroller/base/default) in which focus_highlight is set to "on".
Solution: Now focus highlight in_theme is set by list item theme.
Test Plan: elementary_test->"List Focus"
Reviewers: seoz, woohyun
Reviewed By: seoz
CC: nirajkr
Differential Revision: https://phab.enlightenment.org/D572
Summary:
# Added code to handle the case of disabled items.
# Code refractoring of _item_focused_next().
Test Plan: elementary_test->"list focus"
Reviewers: seoz, woohyun
CC: nirajkr
Differential Revision: https://phab.enlightenment.org/D571
@feature
Summary:
# Added "item,focused" and "item,unfocused" smart callbacks.
# Added elm_object_focused_item_get() in elm_widget
# Added elm_object_item_focus_set and elm_object_item_focus_get() APIs for
# Added one argument in existing _focus_highlight_geometry_get(...,is_next)
This is required to find out previous and current widget item.
# Added a elm_win function _focus_highlight_start() which starts the focus
Test Plan: elementary_test->List Focus , List Horizontal Focus
Reviewers: seoz, woohyun
Reviewers Comments: SeoZ - there are some known bugs. we will actively
fix them in a near future.
CC: nirajkr
Differential Revision: https://phab.enlightenment.org/D532
Some widgets override the widget translation but it didn't inherit the base widget's function.
Becuase of it,The language changed won't be properly called in the widget tree.
Now it fixed it.
Call the smart callback in the widget infra so that each widget don't need to hook the smart_translate only for the smart call.
This makes reducing duplicated code and supporting language,chagned from all widgets.
ecore_animator_del, and ecore_job_del.
As all efl public free apis get null as valid parameter, we do not need
to check null. I also removed some null check for other free apis which
were right next to timer/animator/job del. After this job code got
cleaner.
There are elm_widget_theme/theme_set/theme_get functions.
In Eolian these functions will be described as "theme" method and
"theme" property. There is clash here.
So add suffix "_apply" to Eo API for "elm_widget_theme".
Being annoyed by different types of eina critical macros - CRI, CRIT,
CRITICAL -, I concluded to unify them to one. Discussed on IRC and
finally, CRI was chosen to meet the consistency with other macros -
ERR, WRN, INF, DBG - in terms of the number of characters.
If there is any missing bits, please let me know.