Summary:
Patch from a series of patches to rename EAPI symbols to specific
library DSOs.
= The Rationale =
This patch is from a series of patches to rename EAPI symbols to
specific library DSOs.
EAPI was designed to be able to pass
`__attribute__ ((visibility ("default")))` for symbols with
GCC, which would mean that even if -fvisibility=hidden was used
when compiling the library, the needed symbols would get exported.
MSVC __almost__ works like GCC (or mingw) in which you can
declare everything as export and it will just work (slower, but
it will work). But there's a caveat: global variables will not
work the same way for MSVC, but works for mingw and GCC.
For global variables (as opposed to functions), MSVC requires
correct DSO visibility for MSVC: instead of declaring a symbol as
export for everything, you need to declare it as import when
importing from another DSO and export when defining it locally.
With current EAPI definitions, we get the following example
working in mingw and MSVC (observe it doesn't define any global
variables as exported symbols).
Example 1:
dll1:
```
EAPI void foo(void);
EAPI void bar()
{
foo();
}
```
dll2:
```
EAPI void foo()
{
printf ("foo\n");
}
```
This works fine with API defined as __declspec(dllexport) in both
cases and for gcc defining as
`__atttribute__((visibility("default")))`.
However, the following:
Example 2:
dll1:
```
EAPI extern int foo;
EAPI void foobar(void);
EAPI void bar()
{
foo = 5;
foobar();
}
```
dll2:
```
EAPI int foo = 0;
EAPI void foobar()
{
printf ("foo %d\n", foo);
}
```
This will work on mingw but will not work for MSVC. And that's why
LIBAPI is the only solution that works for MSVC.
Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com>
Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev>
Reviewers: vtorri, woohyun, jptiz, lucas
Reviewed By: vtorri, lucas
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12214
Summary: If the inlist has only one item when it removed. the data is not freed in descturctor.
Reviewers: Hermet, raster, vtorri
Reviewed By: Hermet
Subscribers: vtorri, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12147
Summary:
evas_render_updates_internal > eina_array_remove is calling pending_change
pending_change > render_post could call evas_object_change >
evas_render_object_recalc.
The eina_array is removing its item from pending_objects, while
the evas_object_change that is calling evas_render_object_recalc is adding
item to pending_objects.
As a result, the pending_objects.count is incorrect, and it breaks render.
Reviewers: Hermet, jsuya, herb
Reviewed By: Hermet
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11835
Each child_map_across_mark() takes 0.026ms with eina_hash
we can reduce the performing time by replacing the hash to array to 0.0041ms in a device.
Before Average: 0.026ms
Mostly it takes 23 times in the scrolling. thus it takes 3%(0.48ms) in one frame rendering (16ms)
After Average: 0.0041ms
Mostly it takes 23 times in the scrolling. thus it takes 0.6%(0.096ms) in one frame rendering (16ms)
result: map calc 5x faster than original (0.384ms improved)
Thanks Subhransu for report this.
@optimization
sometimes a canvas object is zombying, and does not get freed correctly.
If this is right now happening in our test suite, we are going to free
the list, but do not clean up the pointer in there.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11594
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