reduces the load of debug messages, and the debug messages are now only
emitted from the manager that is not the redirect. And the real elements
that are focused are printed
this now means any app that called elm_config_*set on any field at all
will keep what it set forever until it changes it even if shared/core
config changed.
this now flags about 1/4 of the config vars in elm config if you set
them locally so they wont change on conifg reload. i have just started
and this is the first batch. needs more work.
right now we just request the complete geom to be visible since there
seems to be no way ot checking where the new widgets will be in. This
needs some improvements.
Some things have clearly not been tested. Some APIs have not been
modified after repeated review comments. C++ failed to build due to
"long" being used as a namespace.
Remaining issues:
- The original finger_list API was broken by design. I didn't try to
replace it yet.
- Long tap is also broken by design: if no move happens the recognizer
gets no event, and doesn't trigger anything when the timeout is
reached. An API or event is lacking here.
- Only 2 very basic gestures have been implemented. All the gestures
from elm_gesture_layer need to be covered. None of the multi touch
support has been really implemented, except for a single bool flag.
- The configuration must be loaded from elm_config, passed on to the
recognizers.
- Some micro optimization may be required, especially if the input
device is high frequency (eg. 1KHz gaming mouse).
If the image has no data, it may get an allocated surface of 1x1 but it
is not sane to return the pointer to that data, as the user would expect
a normally sized image (in my case, 1920x1080).
I do not fully understand what is going on with this image. But at least
this transforms a crash into a simple ERR in ~/.xessions-errors
Two similar crashes happened:
- SIGSEGV by writing data outside of the image data
- abort() in free() because the malloc metadata has been overridden
when writing outside of the image data (newly allocated 1x1).
Fixes T5957
@fix
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.
Marcel Hollerbach
Carsten Haitzler
Jean-Philippe Andre
smohanty
Lukasz Stanislawski
Jeonghyun Yun
Taehyub Kim
Shinwoo Kim
Thiep Ha
Cedric Bail
Prince Kumar Dubey
Bowon Ryu