it's broken. it doesnt render anything. input is broken. it isn't in
use so it doesnt justify fixing. no one has complained it's brokne
thus proof of it not in use, so proof that it's not needed, so do the
right thing and nuke it to save work
@feat
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
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
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
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
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 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
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
Summary:
this should not take any action if the existing value of manual_render is
set to the passed value
Reviewers: devilhorns, kimcinoo, ManMower
Reviewed By: devilhorns, kimcinoo, ManMower
Subscribers: ManMower, cedric, #reviewers, #committers
Tags: #efl_display_system
Differential Revision: https://phab.enlightenment.org/D6786
Summary:
We need to pass the entire pointer, not just 32-bits of it.
Fixes a crash with enlightenment sandbox gadgets where
ecore_wl2_window_alpha_get() is called with an invalid pointer while
trying to display a pop-up.
Reviewers: zmike, devilhorns
Reviewed By: zmike, devilhorns
Subscribers: devilhorns, cedric, #reviewers, #committers, zmike
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6775
Summary:
If we call ecore_evas_manual_render() during an async render, it does
nothing.
This is harmful if we've added render post callbacks during that async
render and expect them to fire.
Force a sync and another render if we're in an async render.
ref T7156
Depends on D6714
Reviewers: zmike
Reviewed By: zmike
Subscribers: cedric, #committers, zmike
Tags: #efl
Maniphest Tasks: T7156
Differential Revision: https://phab.enlightenment.org/D6715
Summary:
Some ecore_evas such as ecore_evas_extn_plug doesn't have evas.
ecore_evas_extn_plug seems to be Ecore_Evas, but actually it is Evas_Object_Image.
ecore_evas_extn_plug makes new ecore evas, but it only exists to communicate with ecore_evas_extn_socket.
newly ecore evas only open and close file(ecore_evas_extn_socket). so it doesn't have evas.
```
EAPI Evas_Object *
ecore_evas_extn_plug_new_internal(Ecore_Evas *ee_target)
{
...
ee = calloc(1, sizeof(Ecore_Evas));
...
o = evas_object_image_filled_add(ee_target->evas);
...
return o;
}
```
Reviewers: zmike, Hermet, woohyun, raster, devilhorns
Reviewed By: zmike
Subscribers: cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6504
Summary:
After a44697c37a, we can register same ecore_evas
to ecore_evases using ecore_evas_input_event_register.
(ecore_evas_input_event_register -> ecore_evas_done -> _ecore_evas_register)
This can make infinite loop in EINA_INLIST_FOREACH(ecore_evases, ee) because
next inlist of ecore_evases is ecore_evases after double call of
_ecore_evas_register.
This patch prevent it.
Test Plan:
Ecore_Evas *ee = ecore_evas_new(NULL, 0, 0, 800, 600, NULL);
ecore_evas_input_event_register(ee);
(part of document of ecore_fb_input_device_window_set)
Check that there is no infinite loop
Reviewers: zmike, devilhorns
Reviewed By: zmike
Subscribers: cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6390
This reverts commit 2fb5cc3ad0.
Most of this change where wrong as they didn't affect the destruction
of the object. efl_add_ref allow for manual handling of the lifecycle
of the object and make sure it is still alive during destructor. efl_add
will not allow you to access an object after invalidate also efl.parent.get
will always return NULL once the object is invalidated.
Differential Revision: https://phab.enlightenment.org/D6062
so i found the work with wayland and having animator sources broke
that same source from ecore_x that was there from long ago, so i've
put in an exception if there are x based engines from restting to a
timer animator because ecore_x would have switched toa custom ticker
already, and this just resets it. also just set the source after
setting the tick callbacks and ensure tick cb's are null before going
to timer source as well. this cleans up this little but of animaatior
vsync modification to properly vsync in both x and wayland too now.
@fix
so the MAIN loop is actually an efl.app object. which inherits from
efl.loop. the idea is that other loops in threads will not be efl.app
objects. thread on the creator side return an efl.thread object.
inside the thread, like the mainloop, there is now an efl.appthread
object that is for all non-main-loop threads.
every thread (main loop or child) when it spawns a thread is the
parent. there are i/o pipes from parnet to child and back. so parents
are generally expected to, if they want to talk to child thread, so
use the efl.io interfaces on efl.thread, and the main loop's elf.app
class allows you to talk to stdio back to the parent process like the
efl.appthread does the same using the efl.io interfaces to talk to its
parent app or appthread. it's symmetrical
no tests here - sure. i have been holding off on tests until things
settle. that's why i haven't done them yet. those will come back in a
subsequent commit
for really quick examples on using this see:
https://phab.enlightenment.org/F2983118https://phab.enlightenment.org/F2983142
they are just my test code for this.
Please see this design document:
https://phab.enlightenment.org/w/efl-loops-threads/
Summary:
This patch fixes a tentative crash owing to ptr dereference.
Unlike ecore_evas_object_cursor_set and ecore_evas_object_cursor_device_set,
ecore_evas_cursor_set uses Ecore_Evas *ee before calling internal function which
internally checks null ptr dereference of Ecore_Evas *ee.
Test Plan: Executes test suite
Reviewers: cedric, raster, stefan, Jaehyun_Cho
Reviewed By: Jaehyun_Cho
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D5753
because as of... i don't know when, evas relies on ecore with
ecore_pipe_add to create the async fd... and if you init evas then
ecore this doesnt work. obviously. well now it isn't working. probably
due to new efl loop work. but the efl loop code is correct.
ecore_pipe_add should never work until you init ecore... it just
happesn to have managed to be gotten away with for a while.
@fix
Carsten Haitzler
Christopher Michael
Vincent Torri
Marcel Hollerbach
Xavi Artigas
Cedric Bail
Hermet Park
Mike Blumenkrantz
Derek Foreman
Yeongjong Lee
Hosang Kim
YeongJong Lee
Cedric BAIL
Derek Foreman
Chris Michael
Myoungwoon Roy, Kim