Since ecore now uses efl events to feed input events to the
canvas, anyone can now listen to any event on the evas. But
when using the legacy API the event info needs to be the legacy
struct, and not the eo event info otherwise crashes will happen.
While this is a new use of events, I consider it valid and it's
better to fix it rather than disallowing it. Fixed by wrapping
evas events the same way evas object events were handled.
Fixes T5266
The previous patch (b184874fa5) was preventing
post-event callbacks from triggering any form of input event,
including side-effects due to mouse,in. In fact by tracking
which exact events we want to post-process we can support
proper recursion. This fixes crashes in Bryce.
I'm not changing the documentation as this is still a dubious
code design.
Fixes T3144
Fixes T5157
See T3144 that I marked as Wontfix.
Bryce in E manually feeds events from a post-event callback
resulting in Evas going insane and leading to frequent crashes.
The ideal solution (for E) would be to ensure that everything works
smoothly, the input event data is valid up until the post-event cb
is called, etc... Unfortunately, with recursive events the exact
order of operations may be messed up: the post-event
I don't want to add yet more complexity to Evas events here (it's
already spaghetti all over the place) so I'm simply blocking any
new event feed when running the post-event callback list.
It's not possible to just freeze the events (I tried, it failed).
**********************
Some more explanation:
post-event callbacks are used to implement reverse-order logic
where the on-hold flag of an input event may be set by an event
listener that does not come first.
Here's a situation to illustrate: scroller A inside scroller B.
As events are propagated from children to parents (assuming the
propagate flag is set), we'd assume the events to go first to A
and then to B, which means a mouse wheel event would make the
inner-most scroller (A) scroll, and the outer-most scroller (B)
wouldn't budge.
But as things are designed, A and B are not simple evas objects,
and the actual event-catching object is a top-most transparent
rectangle (top-most in Z stack order). Since A is inside B, B's
rectangle BR is over A's rectangle AR, thus catches the wheel
event first. But in terms of UX we still want A to scroll, not B.
The solution then is to reverse the event processing order and
post-event callbacks are the way to do that. This comes with the
consequence that the event_info needs to remain valid until the
post-event is called, and stay the same (so that the on-hold flag
set by A can be read by B).
Recursive events (by explicit feed or modifying the canvas so
that mouse,in or mouse,out are triggered) mess with this logic,
and trigger the post-events too early (event is not fully
processed) or too late (event_info is not valid anymore... and
crash!).
Thanks @raster for explaining the goal of post-event callbacks!
A use of the post event callback in Bryce triggered a double free
as an event was being processed but not yet removed from its list,
leading to an invalid state of the Eina_List.
Also remove obj from struct as it is unused.
Fixes T5157
In case of a mapped object (eg. when applying a map to a window
in wayland compositor), the canvas and output coordinates are
not meant to be the same.
In EO land, applications should instead use the common interface
Efl.Input.Interface.pointer_xy.get (on the canvas).
@fix
before changing MAGIC_CHECK to eo_isa passing NULL to a function would
result in nothing, now it gives a error message. This restores the old
behaviour.
After my many input events changes, a same object callback
could be called multiple times in a row because both mouse
and multi events were sent. As such, the multi event had no
direct effect (no callback called) but it reset the object's
last event type. This allowed the mouse event callbacks to be
called again.
Note that I haven't tested multi touch yet :(
Very good catch by @bu5hm4n!
Fixes T4462
Fixes T4467
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 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 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 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.
Since the new event type is the same for multi and single
touch (finger id is the only difference), multi touch listeners
would get triggered even for single mouse events.
Fixes https://phab.enlightenment.org/T4345
Fixes https://phab.enlightenment.org/T4378
This raises a question though: How do we want to differentiate
between single & multi touch events in the eo interfaces?
The previous patch 1185c40e50 shows how having
two event types for the same thing (key or mouse input events)
was a bad idea. The only guaranteed order of callbacks is the
priority but even that was not enforced (since legacy or eo
style event had to come first).
Fixes T4310
This affects pointer & key events.
Here's the scenario: in Enventor, an elm_button object
grabs the up & down keys for the autocompletion feature.
But the entry will also listen to up & down to move the
cursor. Moreover, the scroller listens to up & down arrow
keys to scroll around.
So, when calling the new eo event first, the scroller
or the entry would catch it and do some action. In
Enventor, this triggered a hide on the magic anchor
object. Bad, bad.
I fear something will be wrong with this order as well.
Both events (legacy & eo) should be called simultaneously,
following the order & priorities that were set.
This being said, in real life most of EFL internals will
move to the new eo events (right now elm relies on the
new events, but edje doesn't, yet), so any app grabbing a
key probably wants to handle the event before elm. Same
for an app using focus manually.
Fixes T4310
UP/DOWN arrows were having effects on both focus and entry cursor
moves. This was due to an invalid propagation of the changes to
event_flags (on_hold).
Fixes T3845
So, I was stupid. I was relying on legacy callbacks to
trigger eo events, which means that only when a legacy
callback was registered would my new eo events be triggered.
Instead, I can pass the eo event desc & info whenever
calling evas_object_event_callback_call().
If on_hold or on_scroll is set in an eo callback, the subsequent
calls to the legacy callbacks will also have this flag set.
Inversely the legacy callbacks should affect all subsequent eo
callbacks.
Note: those are just indicative flags.
This is going back to the same idea as legacy. We will have
events such as:
- move
- down
- up
- in
- out
- wheel
- cancel ("new" - very rare)
Now the question is whether/how we should divide "multi" events
which start from the 2nd finger from standard mouse events. The first
multitouch finger should by default look like a mouse event.
This continues the work started in the previous commit:
forward full event info (Efl_Pointer_Event) from evas to
the upper layers.
This also includes more support for IN and OUT.
This is still VERY experimental and not fully done yet.
All other pointer events need to be sent as well.
The legacy event system is used as a transportation mechanism,
as it is too hard to change the logic. This only adds an extra
eo event in case of move. Obviously for performance we might
want to listen to callback_add,del but that's an optimization
for later.
The whole point of sending those pointer events is to carry more
information than can be sent over legacy evas events, and unify
the events in a common format.
Jean-Philippe Andre
Cedric BAIL
Carsten Haitzler
Guilherme Iscaro
Marcel Hollerbach
Tom Hacohen
Vitor Sousa
Jean Guyomarc'h