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)
Daniel Juyung Seo
Jae Yong Hwang
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