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
Summary: I had fixed some typos and some wrong expressions in API reference doc
Test Plan: N/A
Reviewers: raster, zmike, Hermet, segfaultxavi
Reviewed By: Hermet
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6943
Summary:
this is a simple implementation of ignore_events functionality which
sets pass_events if it's an image or prevents the emission of events
in other cases
the result should be that no user events are received. this deliberately
does not block the triggering of resize callbacks as in the original ticket
since this guarantees broken functionality and is just not a good idea
fix T4700
Reviewers: devilhorns, Hermet
Reviewed By: Hermet
Subscribers: Hermet, cedric, #reviewers, #committers
Tags: #efl_display_system
Maniphest Tasks: T4700
Differential Revision: https://phab.enlightenment.org/D6876
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