Focus highlight can be on the air, when focused object in scroller is
moved by mouse down and move.
So, mouse up is not proper for executing focus_auto_hide.
@fix
The visible bug for this issue is that the Elm External Video example
is broken:
elementary_test -to "ExtVideo"
The root cause is that the "file,choose" event of the
FileselectorEntry is (wrongly) not listed by the function:
evas_object_smart_callbacks_descriptions_get()
This evas functions is used in elm_external to forward all the widget
events to edje, but it cannot forward the "file,chosen" event because
it's not listed.
Thus the video test is not working for the lacks of that event.
I think the fix should be somewhere in elc_fileselector_entry.c, there
are some hacks there for the incriminated signal, but I don't know how
to properly fix.
as pointed out by dave:
DaveMDS added a comment.Fri, Aug 26, 5:19 PM
I think the problem is in this function: (elc_fileselector_entry.c)
...
this fixes T4337
In a case where eina_promise_then is executed immediately (like with some
quick and light Efl.Model), the Listing_Request struct will be prematurely
freed in the first iteration of the child processing loop, because the
item_total counter had not accumulated the right number of items yet.
With this commit, we traverse the children accessor first, so we can know
the number of items.
Also, no longer use the Listing_Request pointer after the loop, once it
may have been deallocate already.
And put a note about this too.
This one is a bit tricky... When we create the aggregated
promise, if one of the properties of the model returns an
error, the eina_promise_then() will immediately call the
error callback. In this happened for the first item, the
total items in the listing request would be 1.
Before this commit, we tested for incremented the processed
counter and compared it to this total count. If it was
greater or equal, we would free the common listing request.
But in the case of successive failures, we would set the
total counter to 1, then the processed counter to 1 and
therefore free. Then increment the total counter to 2, then
then processed counter to 2, and free again... which would
cause an abort() from the libc or something else nasty.
Now we just decrease the total count of items. We avoid
the cases and double frees, without leaking.
The carray iterator will end iterating only when it finds a NULL
object. We must make sure the last element of the array is NULL
to avoid out of bounds access.
Mac OS X does not support POSIX unnamed semaphores, only named
semaphores, which are persistant IPC: when the program exits,
and if semaphores where not released, they stay forever...
All EFL programs were "leaking" a semaphore, due to how
eina_log_monitor manages its resources. Therefore, after building
EFL a lot (which run eolian_gen, eolian_cxx, elua, edje_cc, ...)
we were not able to create any semaphore...
Now, we get rid of these semaphores and use Mac OS X's own
semaphores. Code is less cumbersome, and we don't have any
disavantage of the named semaphores.
Fixes T4423
@fix
Efl.Object.event_callback_call no longer calls legacy smart callbacks;
calling only event callbacks registered with the given event description
pointer.
Create the method Efl.Object.event_callback_legacy_call to inherit the old
behavior from Efl.Object.event_callback_call, calling both Efl.Object events
and legacy smart callbacks.
Update all other files accordingly in order to still supply legacy
callbacks while they are necessary.
This simply avoids calling functions on NULL objects, since
the previous patch would ERR out rather than silently ignore
the problem.
I just add explicit NULL checks before calling the functions,
so it's clear the object could be NULL (in the widget).
This removes useless magic checks (only check whether the
arg is not null) that were not even present in every function.
The cost should be similar or lower than an eo function call.
This removes:
Efl.Event interface
And renames:
Efl.Event.Input -> Efl.Input.Event
Efl.Event -> Efl.Input.Event (merged)
Efl.Event.Pointer -> Efl.Input.Pointer
Efl.Event.Key -> Efl.Input.Key
Efl.Event.Hold -> Efl.Input.Hold
This also moves some interfaces from efl/ to evas/ where they
belong better.
This allows renaming Eo_Event to Efl_Event.
This is for Wacom graphics tablets (with a pen).
The raw data sent by ecore to evas (and then to apps) is pretty
useless as it's not normalized, and apps have no way of knowing the
dimensions of the tablet, without themselves opening the device
(we don't know nor expose the path to the device).
This is for Xi2 only for now, as Wayland support hasn't been done
yet.
The intent is to deprecate LABEL_X and LABEL_Y. I'm not sure yet
if the normalized value is useful or not (it would seem we may not
be able to provide this info in Wayland).
The new WINDOW_X, WINDOW_Y labels will be used in the new event
type (Efl.Event.Pointer). Normalized values are not exposed yet,
let's decide if we want them or not first (based on what can be
done in Wayland space).
@feature
Mice in X with xi2 send Axis events which are badly defined,
and carry basically useless information, as we also receive
proper mouse events. Notably, all mice input events are
"Rel something" but in fact they are absolute values (even
the wheel information is a counter increasing every time you
scroll).
This should not break any application as such axis events
carried only values with label ECORE_AXIS_LABEL_UNKNOWN.
This also fixes a leak when n == 0 (no "valuator" found
in the list, this used to be unlikely, now happens at every
mouse event).
This converts Evas_Axis or Ecore_Axis info arrays into basic
pointer data. Also marks those fields as set. All events need
to properly implement the value_has property (mark all bits
whenever a value is known).
This sets a bit whenever a callback listener is added.
I couldn't get any profiling data easily (too small for
valgrind).
Note: This removes the proper refcounting on the "move"
event listeners. I believe this is not a problem as most times
the move_ref goes to 0, it is because the object is deleted.
Worst case, we just trigger a callback_call with no listeners.
This adds 32 bits to each evas object private data.
This event should not be exposed at all, it's not necessary
anymore, EFL_EVENT_DEL already exists and should be good enough.
This does move the callback call a little bit ealier in the del
process, but at first glance, this shouldn't have any impact.
This moves MULTI events to those new finger event types,
and also sends a finger event for finger 0 (aka the pointer).
NOTE: This may require a separation between a mouse input and
an actual finger touch. To be defined, ie: do we let the app
check the input device info to decide whether the event is
actually the first finger of a multi touch device, or do
we want to send only actual finger events from multi touch
devices only?
@feature
This is getting trickier, as those events have a lot more
side effects and complexity than a simple wheel event...
Some code has been added that should be fixed in the following
commits.
So glibc has decided that readdir_r is hard to use safely and deprecated it
this summer. They recommand to use readdir, which was in the past unsafe to
use in a multi thread scenario, but is now on most system (and all system
we care, including our own implementation in evil). It is basically safe
as long the same DIRP is not accessed from another thread. This is true in
our code base, so we are fine to go with this.
For further reading: https://lwn.net/Articles/696474/