@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.
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.
not backporting because not sure if correct, but definitely a bug
also there's a similar issue where objects (I'm looking at you, elm_list) don't size until the first render, which causes the initial genlist calc sizes to be 100% wrong every time
Scenario:
1. Create elm_genlist.
2. Add some items to it.
3. Do not resize the genlist and leave it with width == 0.
PROPOSAL:
1. When the element is queued for recalculation check current width of
widget. If it is equal to 0 do not add idle enterer.
2. In smart callback on resize check if queue of items that need
recalculation is not empty and new width is not 0. In this situation
add idle enterer.
Summary: Changes in the _item_realize to decorate the item T576 test_genlist10
Reviewers: seoz, singh.amitesh
Differential Revision: https://phab.enlightenment.org/D358
If we're walking an item and it's deleted, the memory won't go away
immediately in _item_del_pre_hook() as would in _item_del(), then it's
not enough to remove ourselves from the reverse-relative list of the
item we were relative to, we also need to clean our own relative
pointer so we won't touch it later when the item is not being walked
anymore and _item_del() is called.
I was getting this annoying error with espionage application, opening
an interface of an object and then closing the window or selecting
another bus name (whatever would call elm_genlist_clear()).
During the clear process genlist will flag the next item as "walking"
so it's not gone when the current item dies (would happen if next item
is a subitem). The item would run _item_del_pre_hook() but not
_item_del(), but on the next loop iteration the next item would be the
current, then not walking anymore and during _item_del() it would
access it->item->rel which would point to the now-dead item.
Summary:
Some applications like file viewer allow multiple selection only with
Control key was pressed.
Reviewers: seoz, raster
Reviewed By: raster
Differential Revision: https://phab.enlightenment.org/D251
Conflicts:
ChangeLog
NEWS
Genlist will now emit the following signals to item view related to
their position in the whole list:
- elm,state,list,first: first item of the whole list
- elm,state,list,last: last item of the whole list
- elm,state,list,middle: any item that is not first or last.
- elm,state,list,single: when the item is the only element of list.
And the following related to a group (considering its given 'parent'):
- elm,state,group,first: first item of the group
- elm,state,group,last: last item of the group
- elm,state,group,middle: any item that is not first or last.
- elm,state,group,single: when the item is the only element of group.
Unlike odd/even the signals have an extra namespace "list" or "group"
to avoid conflicts with applications that may have declared these
signals themselves for other purposes.
With this patch one can implement easily something like this:
https://developer.apple.com/library/ios/documentation/userexperience/conceptual/tableview_iphone/Art/tv_grouped_style.jpg
stacking become a lot more complex when re-order mode was added, group
headers and more, so simple raise/lower wasn't enough, so this adds 2
stacking markers (rectangles) and objects are stacked above or below
these 2 markers. that basically provides 4 possible stacking slots
that are easy to address, and if you also still raise/lower you get 6
slots. use these markers for stacking so items go into a fixed
stacking layer when they stack around.
I splited ELM_SAFE_FREE refactoring patches. One commit per each file as recommended.
For the detail, please refer 3072dab12f12fe83fb5a628d15efd5cded11787f.
There are pros and cons but this
1. reduces human mistakes.
2. enhances readability.
3. enhances code quality.
4. removes future bug.
5. was adopted from enlightenment.
This is not all. I will work on enhancing elementary more and more.
Summary:
This patch applies automatic focus feature to elm_genlist and elm_list
containers.
Currently (prior to this patch), focusable widgets inside list items of both
containers receive focus by an explicit mouse click over them, and lose focus
when focus goes to someone else in the window.
This change also adds the ability to:
- focus by default on the first-from-right focusable widget upon items selection
- lose the focus when another item is selected (focused or not)
- move focus between focusable widgets inside the same item by left and right
arrow keys accordingly (up and down keys when elm_list is in horizontal mode)
Focus is supported for horizontal and vertical lists.
Tests have been added for genlists and lists to check focus feature.