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:
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)
With Eo2 you can return values directly without the need to use a pointer
(use the C return).
For example:
eo_do(obj, elm_object_text_get(&text));
becomes:
eo_do(obj, text = elm_object_text_get());
@feature
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.
With this new API the user can block movements on X axis, Y Axis or
both. I was left with no option but to come up with this, side by side
with elm_object_scroll_freeze_push(), elm_object_scroll_hold_push()
and elm_object_scroll_lock_x_set() (or
elm_object_scroll_lock_y_set()), once all of these will act on *parent
and/or child* widgets too, making those useless for any pratical use
of scroll blocking. Here's a sane, new option, enjoy it.
1. Do not need to print the same error message from all the widget codes.
2. Even though elm_widget_sub_object_add() can be used internally, there should be no error message at all.
Elm devs should fix it beforehand.
So it looks ok to print the error message in elm_widget_sub_object_add() to force elm devs to fix it.
3. Got additional code cleanups.
When the scroller is resized, the signals("elm,action,scroll", "elm,edge,top" so on) shouldn't be sent,
because it's not a scroll-action. So in this case, the content_pos_set should be called without the signals.