Summary:
If User want to content set something to item area. there is no way to except elm customizing.
So i added this feature and make the toolbar item object to layout before.
Now user can content set something on item area only call "elm_object_item_part_content_set" API.
Test Plan:
Make some swallow part on toolbar edc.
and content set some layout to that swallow part to using "elm_object_item_part_content_set"
Reviewers: cedric, Hermet
Subscribers: SanghyeonLee, eagleeye, id213sin
Differential Revision: https://phab.enlightenment.org/D2777
Summary:
Its for support elm_object_item_XXXX APIs for toolbar item.
Its the pre work for toolbar item content set some layout to toolbar item layout automatically.
(without implement item_content_set with part name.)
I abandoned for check the other side of this change. but its not has problem so i reclaim this commit
and put on another commit for this. https://phab.enlightenment.org/D2777
Test Plan: To all of the action on elementary toolbar test sample.
Reviewers: cedric, Hermet
Reviewed By: cedric
Differential Revision: https://phab.enlightenment.org/D2768
Summary:
incorrect evas_object_box_children_get usage: returned list must be freed
@fix
Reviewers: cedric, seoz, raster, reutskiy.v.v, Hermet
Differential Revision: https://phab.enlightenment.org/D2412
when insert a new item before/after an item, the relative item should not be NULL.
this patch fixes naviframe, gengrid, genlist, list, and toolbar.
@fix
Summary:
In case of the toolbar item size is fixed, the size of toolbar item became finger size.
so, after signal emission in _inform_item_number(),
edje_object_size_min_restricted_calc() and evas_object_size_hint_min_set() function are added.
Test Plan: change edc for supporting fixed toolbar item and run examples of toolbar in elementary_test
Reviewers: woohyun, seoz, Hermet, raster
Reviewed By: raster
Differential Revision: https://phab.enlightenment.org/D2184
Summary:
elm_coords_finger_size_adjust() is called twice.
It might not be intended.
Reviewers: Hermet, Jaehyun, seoz
Reviewed By: seoz
Subscribers: raster, seoz, Hermet
Differential Revision: https://phab.enlightenment.org/D1924
Summary:
size_hint_align was used instead of evas_box's internal value for aligning
of internal items. Because of that layout functions of elm_box and evas_box
were incompatable
Fixed elm_box, els_box layout and widgets that used this behaviour.
@fix
Test Plan:
Run "elementary_test". All buttons should be left-aligned
"elm_box_align_set(tbx2, 0.0, 0.5);" (test.c:332)
Reviewers: cedric, Hermet, stefan_schmidt, seoz
Reviewed By: seoz
Subscribers: shilpasingh, reutskiy.v.v
Differential Revision: https://phab.enlightenment.org/D1512
This change is not simple because Elementary has not been built from the
first day to work with Eo. Code had to be adapted to fit the new design.
The del_pre that have not been replaced yet can return FALSE and
prevent deletion. For these classes, code modification has to be deeper
and will be done later.
Summary:
Change requested by TAsn. Previuosly AT-SPI headers were kept private
and included directly into elementary source code. From now on,
AT-SPI headers can be included from Elementary.h public header, however
will be marked as beta APIs.
Commit includes following changes:
* include all atspi headers into new elm_interfaces.h header.
* marking all at-spi interfaces methods/properties as @protected.
* wrap all common headers with EFL_BETA_API_SUPPORT.
* make some common APIs visible in lib, by adding EAPI attribute
(if someone decides to use beta APIs).
Test Plan: out-off tree build with gcc, g++
Reviewers: tasn
Reviewed By: tasn
Subscribers: seoz, q66, kuuko
Maniphest Tasks: T1721
Differential Revision: https://phab.enlightenment.org/D1528
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: 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
- Item based widget should emit this signal. This is good for the
consistency and makes application developers easy to guess.
- Added test case to elementary_test -> toolbar
@feature
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
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.
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
Amitesh Singh
woochan lee
Avi Levin
Daniel Kolesa
Lukasz Stanislawski
Tom Hacohen
Andrii Kroitor
Jaeun Choi
Mike Blumenkrantz
taehyub
WooHyun Jung
Subodh Kumar
Daniel Juyung Seo
Jee-Yong Um
Daniel Zaoui
Anil Kumar Nahak
Hosang Kim
Zbigniew Kosinski
zmike