OMG... I do not like this patch.
See T6148, two key down events are received when a key grab is installed
on a Win object. This is because all input events are propagated from
ecore all the way up to win and can be listened on. Unfortunately this
breaks existing applications that use the key grab API properly to
listen to key events.
Another side effect is that ALL key events are received by the window,
which means it's not limited to what the application expected (from its
list of grabs).
Solution (ugly): block propagation of key down/up events if the window
is a legacy window. This means that no key grab is required for EO
windows, but key grabs are still required for legacy windows.
Fixes T6148
@fix
Use content_region_show instead of content_pos_set in _key_action_move
Summary:
When user keep pressing key down or else on scroller content, scroller
animation is lagging because of elm_interface_scrollable_content_pos_set
by step_x or step_y value. When focus moved to next object by press key
down or else, content_pos_set by ecore_animator continuously. In this
time, content_pos_set in _key_action_move by step_x or step_y value
caused animation lagging problem. I fixed to use content_region_show
instead of content_pos_set in _key_action_move for remove exist
animator.
Test Plan:
1. elementary_test -> Scroller3
2. Press 3 times "Append 10 Items in 3s" button
3. focus to Item1 and keep pressing key_down
Reviewers: jpeg, woohyun
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5278
This is:
- using a property (but terribly ugly due to the ownership on the
returned value)
- removing an unused function
Note: This interface Efl.Config covers only elm_config for now. But it's
very generic and could be used in the future for application specific
configuration.
This creates efl_ui.eot
It's not called efl_ui_types.eot because a file with that name already
exists in efl/interfaces (for Efl.Ui.Drag functions).
Also add some FIXME comments, and move some types to elm_widget_item.eo.
Ref T5329
Before screaming in horror (C++...) here's why we may need this:
Efl.Part.part API returns an object that is by definition valid for a
single function call only. Enforcing this in practice is actually quite
hard as all implementation functions must manually take care of the
life-cycle. This is a lot of code in many places and a lot of
opportunities to forget to properly handle that life-cycle. Also, this
means any invalid function call on a part will leak an object.
This API absolutely must remain either "internal" or "beta" and
definitely not become abused by applications. On top of that such an API
can cause great trouble for bindings like C++. As a consequence, only
specially crafted APIs like efl_part() should return an object marked as
auto_unref.
Alternatively this API could be defined in Eo.h or some other
Eo_Internal.h. I placed it in efl_object.eo because it's much more
convenient :) (read: I'm lazy)
****
Performance notes:
Tested with clang & gcc (with -O2), I had a look at the output of perf
top, in particular the asm view. I used eo_bench in a loop. My
conclusions are:
- EINA_LIKELY/UNLIKELY actually works. The jump statement varies
according to the expectation. I highly doubt all those ugly goto in
eo.c / Eo.h are even useful.
- The impact of auto_unref on a call_resolve is so small it doesn't even
appear in the trace. It is significant inside call_end, though
(obviously, that function is just a few lines long). That function
accounts for ~1% to ~4% of all CPU time. The impact of auto_unref in
call_end is ~4% of the function time. This means ~0.16% of all CPU
time (worst measured case). _efl_object_op_api_id_get simply doesn't
show up because of caching, so the extra check there is negligible.
PS: I also tested EINA_LIKELY/UNLIKELY by compiling with -O2 and looking
at the output with objdump. The flag is well respected, and the jump
instructions are what you would expect (no jump for LIKELY and jump for
UNLIKELY). Conclusion: The goto's in eo.c only make the code harder to
read...
Before this patch, the key would always be zero and the hash would solely
rely on the rbtree to be efficient. This improve the situation by using the pointer
as the key during hash computation.
Summary:
Some parameter's name are different in annotations and statements,
so it occurs doxygen warning.
To fix it, rename that parameters.
Test Plan: API Doxygen Revision
Reviewers: raster, cedric, jpeg, myoungwoon, Jaehyun_Cho
Differential Revision: https://phab.enlightenment.org/D5327
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
Putting local variable "d" under preprocessor flag "EINA_SAFETY_CHECKS" to avoid below warning, if "EINA_SAFETY_CHECKS" is disabled.
1. local variable "d" is assigned but not used.
2. If warning 1 is resolved then variable "d" will be unused.
Reviewers: raster, cedric
Reviewed By: cedric
Subscribers: jpeg, rajeshps
Differential Revision: https://phab.enlightenment.org/D5321
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary: assignment to local variable "ret" has no meaning as it is not used after assignment. So, removing assignment operation to avoid warning.
Reviewers: raster, cedric
Subscribers: jpeg, rajeshps
Differential Revision: https://phab.enlightenment.org/D5303
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
#finally
For now we focus the widgets of a item, the item content can be cycled
by tab / Ctrl + tab. up/down/right/left are for now handled by gengrid
and move the focused item (everything else feels super weird with
multiple contents in a item)
ref T6181