Summary:
- added is_active property in Evas_Key_Grab.
- Evas key down and key up events transferred to active grabs only.
- If evas grabs has a exclusive grab, other grabs will be deactivated.
- If a exclusive grab is ungrabbed, remained grabs will be activated.
Reviewers: jypark
Reviewed By: jypark
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3996
elm_win have three feature releated with screen.
1. screen_rotation_get
2. scrren_size_get
3. screen_dpi_get
so create efl_screen interface, and elm_win implement that interface
Summary:
We did the same for evas_canvas3d_scene_pick(see c850cc0d80),
but forget for evas_canvas3d_scene_exist.
Reviewers: Hermet, raster, cedric
Reviewed By: cedric
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D3973
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
It is logically break cycle in case object is found. In case need pick all objects
that lay in screen ray, we should use evas_canvas3d_scene_pick_member_list_get
function.
Reviewers: Hermet, raster, cedric
Reviewed By: cedric
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D3975
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
- elm_map has a scrollbale interface and it is set
as ELM_SCROLLER_SINGLE_DIRECTION_SOFT by default.
- elm_map can be rotated by gesture or by an API
elm_map_rotate_set, so this single direction
makes scroll unnatural.
Reviewers: Hermet, cedric
Subscribers: conr2d, jpeg
Differential Revision: https://phab.enlightenment.org/D3986
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
We do properly unref promise while calling all the then callback. There
is no need to check it a second time (which actually lead to a 100%
bad access).
T3759
Small patch to deprecate Ecore_Drm. This patch also adds a configure
option to enable ecore_drm for older code. This option is disabled by
default, so must be explicitly specified during build.
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
For ecore_evas drm engine(s), disable setting of
ecore_event_window_direct_callback as this Completely Breaks all input
when running Enlightenment Wayland.
NB: This can likely be re-enabled at some point, when the jpeg
breakage is over ;)
@fix
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
This adds a few classes, in particular Efl.Event and Efl.Event.Point
which are used as the event info for all pointer (mouse, multi) call
Using an eo object as event info will allow for future extensions
really easily. We don't need to expose any of the internals, also
a single type can be used for all pointer events.
Still TODO:
- Keyboard events (urgent)
- Axis / Joystick events (needs porting from Tizen)
- Gestures support (probably later)
- Event feeding from app side (manual feed)
Not going to be ported to EO:
- Hold API and hold event. Seems barely used.
The new APIs are not very much tested at this point, and rely on the
old legacy event system. The most important thing right now is to
ensure that nothing was broken so far. Unfortunately I can only do
this much testing myself...
Merge branch 'devs/jpeg/work'
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 moves Efl.Pointer.Event back to Evas. Originally I wanted
to share this class with Ecore but eventually I didn't need to
do so, since only ecore_evas (which depends on evas) really needs
access to these.
The internal data struct is not moved out of efl (yet?)
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.
This whole input system is a massive mess. It looks like spaghetti.
Long live the giant flying monster.
This commit changes how some events are propagated in X.
Before:
ecore_x -> evas_event -> evas
After:
ecore_x -> ecore_input_evas -> ecore_evas -> evas_event -> evas
There are still inconsistencies between events and between X and WL,
but ecore_evas should be used for all events since it rotates the
inputs.
This way, ecore sends eo events to evas, which can then
be listened to by other clients (FIXME: the events will
need to be propagated from evas to the elm window).
Current support:
- mouse/multi down
- mouse/multi up
- mouse/multi move
- mouse wheel
Since the direct input event callback returns true if the
event has been processed, we can easily support legacy and
progressively implement full support for eo input events.
This object is the data carried over in an event data pointer.
The private data should be accessible by Ecore and Evas, but
not externally. This means we should be able to easily extend
the feature set, adding more and more information, without
breaking API / ABI.
Also, this should allow applications to create fake input
events easily without exposing our internal structures, or
functions with more and more parameters (such as feed multi).
This is only a storage class, shouldn't contain any logic.
In the future, some logic may be added for gestures support
for instance, or input smoothing / resampling (eg. if input
frequency is 90Hz and screen refresh rate is 60Hz).
The aim is to replace:
- Evas_Event_Mouse_Xxx
- Evas_Event_Multi_Xxx
- Ecore_Event_Mouse_Xxx
We might want to also support Axis, Gestures, etc... with the
same model or even same storage class.
So, this is not a very clean solution, but this mostly
makes Evas_Device an Eo object of class Efl.Input.Device.
Since evas_device relies on some Evas knowledge (evas
callbacks, canvas private data), it can't be fully moved
to lib/efl/.
Making the input device an interface rather than a class
was also not a great solution, as the goal is to share
the data structure around EFL internals (Ecore and Evas).