Note: it seems the EAPI evas_touch_point_list_xy_get() was
lst at some point, as it doesn't appear in the headers anymore.
It looks like we fail to catch an ABI break! abi_checker didn't
catch this!?
Ref T5312
This implements an entirely new API model for Evas Map by relying
on high-level transformations on the object rather than an external
Evas_Map structure that needs to be constantly updated manually.
The implementation relies on Evas_Map.
To rotate an object all you need to do now is
efl_gfx_map_rotate(obj, 45.0, NULL, 0.5, 0.5);
Or with a C++ syntax:
obj.rotate(45.0, NULL, 0.5, 0.5);
Or even simply (with default arguments):
obj.rotate(45.0);
The map transformation functions are:
- rotate
- rotate_3d
- rotate_quat
- zoom
- translate (new!)
- perspective_3d
- lightning_3d
@feature
to date if you use async preload we still load the header
synchronously and this can be horrible especially with generic
loaders. there is no way to farm this off to the preload thread. now
there is. youhave to set it as a skip head load option before doing a
file_set AND you need to issue a preload ... but now it's possible.
@feature
Summary: Due to implicit declaration, evas_vg_container_child_get casts to int and on 64-bit can return wrong pointer
Reviewers: cedric, NikaWhite, myoungwoon, jpeg, an.kroitor, Hermet
Reviewed By: Hermet
Subscribers: t.naumenko
Differential Revision: https://phab.enlightenment.org/D4464
Clang 3.9.0 told me:
warning: passing an object that undergoes default argument
promotion to 'va_start' has undefined behavior [-Wvarargs]
So I told it to shut up and changed Eina_Bool to int.
Note that edje_edit_state_external_param_set has the same issue.
This was broken for smart objects that are not "clipped smart
objects". This fixes the example evas_smart_object.
NOTE: This EAPI was removed in efl-1.18!
/!\ This was an uncaught API break between 1.17 and 1.18 /!\
@fix
These should be just overrides of Efl.Gfx.visible.set. Many
widgets were handling smart show() and hide() manually, which
means this patch is quite large.
Hopefully this doesn't break anything, obviously. But here are
some widgets known to be problematic, as the old code flow was
really strange (sometimes not calling the efl_super function):
- window
- notify
Similarly to group_color_set, group_clip_[un]set should not
exist and should be a result of efl_super and inheritance.
This patch also removes clip_unset from the EO API and keeps
only clip_set(NULL). The reason is that it will avoid bad overrides
of clip_unset() vs. clip_unset(NULL). This also simplifies the code
a bit. Ideally we should be able to reintroduce clip_unset in EO
if we can have a "@final" tag (like java's final keyword), to
prevent overrides.
This is a poor man's solution to get rid of group functions such
as clip_set, clip_unset, color_set, etc... See the following
commits.
This API needs to be EAPI for elementary but shouldn't be used
outside EFL. This is required purely for legacy compatibility.
Here's the call flow, inside show(obj):
1. if (intercept_show(obj)) return;
2. show(super(obj));
3. do other stuff
Summary:
If native surface is multiple buffer pixmap such as named pixmap, Evas should recreate eglImage everyframe.
Because DDK get the buffer ID once at eglImageCreate time.
So if internal buffer ID is changed, should recreate eglImage.
Test Plan: Wearable Tizen.
Reviewers: wonsik, raster, cedric, jpeg
Reviewed By: jpeg
Subscribers: spacegrapher, dkdk, cedric
Differential Revision: https://phab.enlightenment.org/D4211
Those are marked as EINA_DEPRECATED since they are for legacy only,
and EDC is the preferred method.
Note: these are new in EFL 1.18.
I would rather have not added them as legacy APIs. This patch is
here to align to Tizen which added them by mistake. Also, remove
the "name" argument from filter_program_set as it's not required,
and also not there in Tizen's code base.
Sorry for the mess.
It relies a bit on evas legacy APIs and will only work on
evas objects (Efl.Canvas.Object) for now.
The main difference with Evas_Map is that there is no
separate map object, as the functions apply directly to
any canvas object.
For convenience, most functions will automatically populate
the map if there was no previous map info. While this may
be convenient, the object's size changes still need to
be tracked to update the map info.
Evas.Common_Interface not only had a bad name, it also
wasn't in line with how we can get a loop object, for
instance.
Use eo_provider_find in each implementing class.
/usr/local-efl/include/evas-1/Evas_Legacy.h:3762:30: warning: redefinition of typedef 'Evas_Load_Error'
is a C11 feature [-Wtypedef-redefinition]
typedef Efl_Image_Load_Error Evas_Load_Error;
^
/usr/local-efl/include/evas-1/Evas_Loader.h:126:30: note: previous definition is here
typedef Efl_Image_Load_Error Evas_Load_Error;
^
thank you jpeg :P
This is legacy stuff. I wish we could hide it from our inheritance
entirely. Instead, just make it abstract, remove all functions from
eo (doable here) and rename with the keyword "internal" in the new
ugly java style name.
smart_get and attach referred to an opaque struct, from EO
point of view.
Also, attach was an EO-only function, used nowhere besides
evas object smart itself, and evas grid (which is not EO
public API).
Note: Only two modes are supported (blend and copy).
The Efl.Gfx and Evas enums were different. All other values
were not supported. For legacy compatibility (since GL engine
actually implements some kind of support for all operations),
render_op_set() should still work fine, even though it's not
recommended, and won't work anymore with EO API.
This is a horrible API used for internal optimizations. Which
may or may not be partly broken anyway.
We can do better, in the future. Let's not expose this kind
of API.
Jean-Philippe Andre
Cedric BAIL
Carsten Haitzler
Artem Popov
Subhransu Mohanty
Felipe Magno de Almeida
Daniel Hirt
Minkyoung Kim
Tom Hacohen
Stefan Schmidt
Marcel Hollerbach