this is building parts of efl into a single .so and links all modules
and binaries to it.
The libraries themselfs are build as .a's which are linked together as
.so's. Which is required as every subproject has its little custom
c_flags, which are somtimes conflicting.
After the final .so is then built, all the split up libraries are
replaced with the efl-one. After that the modules and binaries are built
correctly with the correct link on the efl-one parts.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11808
libraries are split into deps, external deps, and pub deps.
Evas engines are refactored to use the predefined engine deps.
this is preparation work for efl-one.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11806
Add it to subprojects which are not using it and remove and old
ELEMENTARY_BUILD define we no longer use. This allows us to have a
central place in the main meson.build file to set this variable.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Reviewed-by: Vincent Torri <vincent.torri@gmail.com>
Reviewed-by: João Paulo Taylor Ienczak Zanette <joao.tiz@expertisesolutions.com.br>
Differential Revision: https://phab.enlightenment.org/D11854
Summary: EAPI must be defined to dllexport when building DLL, and to dllimport when using these DLL. To achieve this, define EFL_BUILD for each library and module, and set DLL_EXPORT unconditionally. Static library are and will be not supported
Test Plan: compilation
Reviewers: zmike, raster, jptiz
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11834
this was using a stringshare reference that was deleted. While that is
true, the stringshare reference will always be alive, because 2 people
took a reference. Anyways, this code is now searching the other way
arround, which makes the code also easier.
fixes: CID1420331
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11712
Summary:
ecore_x_dnd_send_status can be used to indicate if a item can be dropped
on a client or not. However, we should only indicate that this can be
dropped, if there is a object we signaled that a drop is in.
Long story short: there is no assertion that after indicating that
things can be dropped, that a notify for the data is sent. A drag
implementation should always listen to a mouse up event, and abort the
drag if no further operations are sent.
Depends on D11698
Reviewers: zmike, stefan_schmidt, raster
Reviewed By: zmike
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11699
Some methods were missing the "Drag" or "Selection" namespaces or the _Cb suffix.
Depends on D11219
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11426
Including Eina.Content
And a typo/bugfix in ecore_evas_x.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11204
The idea of copy and paste here is:
- The user specifies the content he wants to have in the selection
buffer with a Eina_Content, these content pointer ownerships are
passed to the called. Internally ecore_evas code will memorieze the
pointer, and pass on function callbacks to the modules, which then do
not have to deal with the ownership.
- In case the module does not specify these APIs, the callback
implementation will be called, which only works for cnp *not* dnd.
- Action and mime types are handled as strings, which allows way better
custom organisations.
(The docs needs improvement)
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11192
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:
integrate mman.h to make Evil private to the EFL, as mman.h does not exist on Windows. After a discussion with raster, i include sys/mman.h only on non Windows platform.
One issue, though, is that src/modules/emotion/generic/Emotion_Generic_Plugin.h has inlined functions using mmap()
Test Plan: compilation on Windows
Reviewers: cedric, raster, zmike
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9542
these function the same as the min size hint versions and enable
distinction between internally-set max size hints and user-set max size
hints
@feature
ref T8122
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D9553
this has been optional and unused by e for a very long time ot try
sync front-buffered software rendering with the wm/compositor. we may
as well remove the bloat that is here that is unused... it's been
inactive for many years anyway.
When user manually free the ecore evas,
it could delete evas internally,
then evas_invalidate would be triggered,
invalidate callback would try free evas again,
this causes double free evas.
TEST SCENARIO:
ee = ecore_evas_new(...);
...
ecore_evas_free(ee);
-> free evas
-> invalidated cb
-> free evas (**double free)
This is a regression bug by 5847886a3f
We encountered a deadlock case in ecore_evas_image_object in ecore_evas_buffer
that only happens if the ecore_evas_buffer has nothing changed to render,
though it's triggered to rendering.
See this normal scenario that is working fine as our intention.
being ecore_evas_render()
...
-> ecore_evas_buffer_prepare()
-> evas_object_image_data_get()
-> increment lock by backend engine. (egl/tbm ...)
-> render()
-> render_post()
-> _ecore_evas_buffer_update_image()
-> evas_object_image_data_set()
->decrement lock by backend engine (egl/tbm ...)
...
end ecore_evas_render()
The problem is, if the ecore_evas_buffer canvas doesn't changed at all,
render post will be skipped, it could lose the chance to unlock the image data.
Now the host can't render anymore since it's image source lost the lock.
@fix
This allow evas test to work with an Ecore_Evas directly. It prevent leaking of memory
in the case of half destroying Ecore_Evas.
Reviewed-by: Hermet Park <hermetpark@gmail.com>
Differential Revision: https://phab.enlightenment.org/D9104
tool was not very helpfull, and additionally, the docuemtnation of it
was completly wrong. After searching through the code where tool was
actaully set (efl_ui_win.c) it turned out that it is actaully the "id"
of the pointer when there are multiple touch events.
ref T7963
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D9135
Summary:
some engines do not have an evas
@fix
Depends on D8971
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8972
There some engine option defines could be generalized from the window system
since those options could be used through wayland, x11 both, and probably so on.
This is a prepartion patch to support msaa in wayland.
ui window needs to deliver engine options (stencil, depth, msaa bits)
to evas engine side, ecore_evas_wayland_egl should have the argument to pass.
Summary:
this interface only contains a single event which is implemented only by the
canvas object
ref T7561
Reviewers: cedric, segfaultxavi
Reviewed By: segfaultxavi
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7561
Differential Revision: https://phab.enlightenment.org/D7905
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
We know the item is in there, so we can remove it directly.
Signed-off-by: Derek Foreman <derek.foreman.samsung@gmail.com>
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D7609
Negative values in shadow geometry make no sense at all, however it's
happening all the time in wayland. Let's throw an ERR so it doesn't go
unnoticed.
Signed-off-by: Derek Foreman <derek.foreman.samsung@gmail.com>
Reviewed-by: Chris Michael <cp.michael@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7434
so ecore_event_evas_shutdown() was getting called much more than
ecore_event_evas_init() - missing an init in the ee + img obj creator
in ecore evas. this adds it in and ensures in allocation failures we
dont over-init or shutdown too.
@fix
so i was seeing ecore evas only rendering every 2nd frame... this is
because it was adding and deleting animatiors every time it rendered
instead of keeping one around as lon as updates where there to render
and then remove it afterwards. this caused nasty timing problems and
thus problems assessing framerate of rendered content etc. etc. ...
not good. this fixes that. this only happened if you only used pure
legacy ecore animators. if you used the efl animator tick events it
worked right.
@fix
this is done in order to make ecore_event_evas_key_down work with this.
The function can be used to simulate interactions with a efl_ui_win. If
this is not added, then the user of ecore_event_evas_key_down needs to
differentiate between buffer engines and the rest of the engines.
Differential Revision: https://phab.enlightenment.org/D7361
a new shiny buildtool that currently completes in the total of ~ 4 min..
1 min. conf time
2:30 min. build time
Where autotools takes:
1:50 min. conf time
3:40 min. build time.
meson was taken because it went quite good for enlightenment, and is a traction gaining system that is also used by other mayor projects. Additionally, the DSL that is defined my meson makes the configuration of the builds a lot easier to read.
Further informations can be gathered from the README.meson
Right now, bindings & windows support are missing.
It is highly recommented to use meson 0.48 due to optimizations in meson
that reduced the time the meson call would need.
Co-authored-by: Mike Blumenkrantz <zmike@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7012
Depends on D7011
Summary:
We have back-ends that can generate their own tick sources, but
ecore_animator_add()/ecore_animator_timeline_add() gives no indication
which backend the animator is running on. This means that all animators
have to cause all currently in use backends to tick.
For example, if under wayland 4 application windows are open, all 4
windows will create ticks when any animator is present.
These new animator APIs that take an evas object allow us to figure out
out the backend and only cause the appropriate one to tick.
Depends on D7040
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: devilhorns, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7041
Summary:
These are the refcounted ticky guts of the signal add/del catchers, we'll
need to use these to start/stop from other call chains in the near
future.
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7039
Marcel Hollerbach
Stefan Schmidt
Vincent Torri
Carsten Haitzler
Xavi Artigas
Christopher Michael
Hosang Kim
Cedric Bail
Mike Blumenkrantz
Hermet Park
Wonki Kim
Chris Michael
Derek Foreman
Yeongjong Lee