the previous commits introduced a abstraction for drag in drop which can
be now used for this here. With this commit all the direct protocol
handling in efl.ui is removed, and only the ecore evas API is used.
Additionally, this lead to a giant refactor of how APIs do work. All
Efl.Ui. interfaces have been removed except Efl.Ui.Selection and
Efl.Ui.Dnd, these two have been restructored.
A small list of what is new:
- In general no function pointers are used anymore. They feel very
uncompftable in bindings and in C. For us its a lot easier to just
listen to a event when a drop enters or leaves, there is no need to
register custom functions for that.
- Asynchronous data transphere is handled via futures, which proved to
be more error safe.
- Formats and actions are handled as mime types / strings.
- 0 is the default seat if you do not know what else to take.
- Content is in general passes as a content container from eina, this
also allows applications to pass custom types
The legacy dnd and cnp API is implemented based on that.
All cnp related things are in elm_cnp.c the dnd parts are in elm_dnd.c
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11190
The filter_event function calling a lot of times when it runs.
This can help performance by reducing the number of calls to the efl_data_scope_get() function.
Reviewed-by: Hermet Park <hermetpark@gmail.com>
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D10437
Summary:
The filter_event function calling a lot of times when it runs.
This can help performance by reducing the number of calls to the efl_data_scope_get() function.
Reviewers: Hermet, smohanty, bu5hm4n
Reviewed By: Hermet
Subscribers: zmike, bu5hm4n, q66, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10437
Summary:
The internal and the API we would like is mostly a canvas API. A lot of the code
in evas is working around the fact that efl_input_device is not defined inside Evas.
This patch is the first step to try to clean this up.
Depends on D10487
Reviewers: zmike, raster, bu5hm4n, Hermet
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T8321
Differential Revision: https://phab.enlightenment.org/D10488
Summary:
only call these if they are subscribed to now
ref T8321
Reviewers: cedric
Reviewed By: cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T8321
Differential Revision: https://phab.enlightenment.org/D10361
many of these functions go directly to evas internals with no eo checks,
and the existing "MAGIC_CHECK" macro has somehow become a useless null
check
type checking here is important in order to avoid crazy behavior when the
wrong object types are passed
@fix
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9364
EFL_EVENT_FOCUS_IN is wrong here, EFL_EVENT_FOCUS_IN is called on object
that received object focus. Not canvas focus, however, the code in the
callback there seems to be mainly for canvas focus handling.
Additionally, in evas_events, the event handler that was listening for
the canvas focus in / out events expected a event type, which is also
not correct, because the canvas focus in / out does not have one. In
order to catch such errors later more easily, there is now a safety
check, so we really fetched the correct seat.
Reviewed-by: YeongJong Lee <yj34.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D9191
it seems we have done here something wrong, EFL_EVENT_FOCUS_IN is meant
to be emitted on objects that RECEIVE focus. This function here however
is called each time the window gets focus, which then might lead to a
object getting focus. However, those are two different things.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D9137
Summary:
these types are not currently being released and eolian should not have
generated legacy code using them
Reviewers: segfaultxavi
Reviewed By: segfaultxavi
Subscribers: cedric, #reviewers, #committers
Tags: #efl_api
Differential Revision: https://phab.enlightenment.org/D8288
this takes the current generated output from eolian for legacy code in
evas and adds it to the tree, then removes legacy references from the
corresponding eo files. in the case where the entire eo file was for
a legacy object, that eo file has been removed from the tree
ref T7724
Reviewed-by: Marcel Hollerbach <marcel-hollerbach@t-online.de>
Differential Revision: https://phab.enlightenment.org/D8107
Summary:
"group" is the name used for interfaces api, so be consistent by using
that naming here too
ref T7584
Depends on D8019
Reviewers: segfaultxavi
Reviewed By: segfaultxavi
Subscribers: segfaultxavi, cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7584
Differential Revision: https://phab.enlightenment.org/D8021
Summary:
For clarity, since there are all kinds of maps, including a navigation map
widget.
Also, corrected some misspellings.
Test Plan: make && make check && make examples all work
Reviewers: cedric, zmike, bu5hm4n
Reviewed By: cedric
Subscribers: Jaehyun_Cho, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7564
Differential Revision: https://phab.enlightenment.org/D7974
Summary:
Eolian adds a per-class BETA guard (like EFL_UI_WIN_BETA) to any method tagged
as @beta. This means that any app (and the EFL code) wanting to use BETA features
has to enable them class by class, which is cumbersome.
This commit replaces the individual guards with the global EFL_BETA_API_SUPPORT
guard, so apps only need to define one symbol to access BETA features.
Any usage of the per-class guards has been removed from the EFL code and examples.
When building EFL the global guard is defined by configure, so all EFL methods
already have access to BETA API.
Efl_Core.h and Efl_Ui.h no longer define EFL_BETA_API_SUPPORT. Apps wanting to
use BETA API have to define this symbol before including any EFL header
(It has been added to the examples requiring it).
Test Plan:
make && make check && make examples still work, but there's a lot less #defines
in the code
Reviewers: zmike, bu5hm4n, q66
Reviewed By: q66
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T6788
Differential Revision: https://phab.enlightenment.org/D7924
there is basically no reason for this API. You can only use the API when
you know the class, when you know the class you can also just know the
function to call to get this API.
The reason this API needs to go is that we don't want to use
polymorphism on class-functions.
ref T7675
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D7900
Summary:
Following our naming rule, rename to like other primitives.
i.e. efl_canvas_rect, efl_canvas_image, efl_canvas_vg ...
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7013
Summary:
an evas may or may not have a parent; this is legacy api and it's all
confusing
Reviewers: bu5hm4n, devilhorns
Reviewed By: bu5hm4n
Subscribers: cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6486
Summary:
ecore_shutdown will trigger object deletions which require common
components to still be active in order to avoid crashes
ref 3433be343779424c5e030ace30e211298cd060f8
ref T7052
Reviewers: ManMower, devilhorns
Reviewed By: ManMower, devilhorns
Subscribers: cedric, #committers
Tags: #efl
Maniphest Tasks: T7052
Differential Revision: https://phab.enlightenment.org/D6475
Technically I do not thing it is a correct behavior to force destroy
reference that evas do not hold, but evas_object are deaply tied to
the canvas they are build on and even after invalidate it is hard
to not have function call that would lead to crash. Making the pointer
incorrect thanks to eo indirection seems safer here.
Summary:
This appears to be called from a delete callback that takes place well
after the eo parent relationship is deleted, however
efl_input_device_get_seat() finds the seat by finding the parent. That
will always be NULL during this callback, so we'll leak the data.
Instead, search all seats for the pointer.
Depends on D6181
Reviewers: zmike
Reviewed By: zmike
Subscribers: cedric, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6182
Summary: Need to check whether Evas_Public_Data is null or not before dereferencing it.
Test Plan: Execute test suite
Reviewers: raster, Hermet, cedric, jpeg, stefan_schmidt, Jaehyun_Cho
Differential Revision: https://phab.enlightenment.org/D5987
Reviewed-by: Cedric Bail <cedric@osg.samsung.com>
This changes a lot of things all across the EFL. Previously,
methods tagged @const had both their external prototype and
internal impl generated with const on object, while property
getters only had const on the external API. This is now changed
and it all has const everywhere.
Ref T6859.
Summary:
move evas_async_events_shutdown: to out of EVAS_CSERVE2 ifdef block
to make it reachable.
Reviewers: cedric, woohyun
Differential Revision: https://phab.enlightenment.org/D5926
Reviewed-by: Cedric BAIL <cedric@osg.samsung.com>