Summary:
If item select callback is elm_genlist_clear and genlist object have many item, elm_genlist_clear was broken.
This reason is due to incorrect code. In Old code, check the item focus after an item was deleted. So, I changed the order of the code.
Before item was deleted, Check the item focus.
@fix
Test Plan: I revised the elementary_test code and tested with that.
Reviewers: raster, SanghyeonLee, seoz
Reviewed By: seoz
Subscribers: bluezery, SanghyeonLee
Differential Revision: https://phab.enlightenment.org/D1418
Summary:
ELM_OBJECT_SELECT_MODE_ALWAYS mode for elm_genlist_item_select_mode
was broken. In the item select routine, item mode(it->mode) was not
checked. So, I added the check routine there.
@fix
Test Plan: I revised the elementary_test code and tested with that.
Reviewers: raster, seoz
Reviewed By: seoz
Subscribers: SanghyeonLee, bluezery
Differential Revision: https://phab.enlightenment.org/D1347
@fix
moved the user callbacks call at the end of the function, so the user
is able to modify the list without making the code below the call to
fail miserably.
Also improved the Genlist Del test to also include this case.
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
better - why?
1. no reliance on fnmatrch headers - have special enums for this so
fnmatch is an internal detail (casefole may not exist)
2. don't leak strduped strings - free them when done
3. have the same code for genlist and grid (dup for now until an
interface makes it the same search interface)
4. improve docs
5. get right @since version
6. use label get func in item class - providing a func won't work when
multiple items of multiple classes exist in the list
Summary:
This patch is dependent on D1193 and D1136.
It will be pushed after D1193 and D1136 patch.
Reviewers: singh.amitesh
Differential Revision: https://phab.enlightenment.org/D1168
Conflicts:
src/lib/elm_genlist.c
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
Summary:
content couldn't be always a elm widget.
After checking whether it's elm widget or not, use widget API
Test Plan:
terminology -> options -> font -> select font and check below error message
ERR<25935>:eo lib/eo/eo.c:603 _eo_call_resolve() in elm_widget.eo.c:8: you called func 'elm_obj_widget_focus_get' (213) which is unknown in class 'Edje_Object'.
Reviewers: raster, cedric, seoz, Hermet
Reviewed By: Hermet
Subscribers: seoz
Differential Revision: https://phab.enlightenment.org/D1186
Summary: The focus of genlist should adjust its position on resizing(shrinking).
Reviewers: seoz
Differential Revision: https://phab.enlightenment.org/D1072
Summary:
The focus of genlist was coming out of genlist's viewport area on resizing(shrinking).
This is fixed in this patch.
Test Plan: elementary_test -to genlist5, elementary_test -to fileselector
Reviewers: seoz, singh.amitesh, nirajkr
Differential Revision: https://phab.enlightenment.org/D949
Summary:
This function allows user to search for item in Genlist.
It takes four search parameters:
1. pointer to function to get text of the item. It could be the same with item's
get_text function. This parameter is added to let user use the specific search key
and to avoid problems with setting item's text, that is not constant.
2. pointer to the item from which search should start.
3. search pattern.
4. fnmatch() flags.
To check it's usage the new test is added to the elementary_test (Genlist Item Search By Text)
Reviewers: cedric, seoz, raster
CC: reutskiy.v.v
Differential Revision: https://phab.enlightenment.org/D566
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
Summary:
On focus_on_selection set, the focus set on genlist item of type ELM_GENLIST_ITEM_TREE rather than
on item content objects.
Test Plan: elementary_test -to "genlist focus"
Reviewers: seoz, eagleeye, SanghyeonLee, raster
Reviewed By: raster
CC: seoz
Differential Revision: https://phab.enlightenment.org/D899
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 "genlist focus"
Reviewers: seoz, SanghyeonLee, eagleeye
CC: seoz
Differential Revision: https://phab.enlightenment.org/D891
As widget and widget item can have different in_theme value (since
30cada369), we need to update in_theme value whenever the widget or
widget item get the focus.
Applied this logic to genlist, gengrid, toolbar first.
List focus is not working well at the moment.
This fixes small focus highlight on the left top corner of genlist
when the genlist scroller is clicked before the genlist is focused.
Special thanks to zmike for the report.
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.
Summary: Genlist/gengrid object geometry was used before this patch but using the pan object geometry is more correct. This can be reproduced when the size of "elm.swallow.content" part is smaller then the size of scroller object, focus animtaion on items is jerky.
Reviewers: raster, seoz, singh.amitesh
CC: nirajkr
Differential Revision: https://phab.enlightenment.org/D818
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)
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.
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.
Jae Yong Hwang
Daniel Juyung Seo
Davide Andreoli
Chinmaya
Anand
Lukasz Stanislawski
Carsten Haitzler
Hosang Kim
Anil Kumar Nahak
ChunEon Park
Shobhit
wonguk.jeong
Amitesh Singh
Zbigniew Kosinski
Tom Hacohen
Kateryna Fesyna
zmike
Hosang Kim
Daniel Zaoui
Jaeun Choi
Mike Blumenkrantz
Amitesh Singh
nirajkr
Andy Williams
Andy Williams
Jaehwan Kim
WooHyun Jung