Summary:
The event descriptions of Evas_Object were hardcoded instead
of declared in evas_object.eo and thus no binding could be aware of
their existence.
Note: Evas_Canvas events were left as is.
Reviewers: cedric, tasn, q66, JackDanielZ
Reviewed By: q66
CC: felipealmeida, raster, smohanty, cedric
Differential Revision: https://phab.enlightenment.org/D1065
I am concerned that we do duplicate the color format of a texture insteed
of reusing the colorspace enum from Evas (that already exist). I believe
this is a side effect of not using Evas_GL_Image for texture.
This let me think that I wont allow this API out of BETA until we reduce
duplication by using Evas_GL_Image as it seems it will also impact the
public API of Evas_3D.
Summary:
This problem occurred due to xkb_keysym_t value of libxkbcommon by e wl server.
e wl server should pass keycode from evdev input device on to wl client.
In order that e wl server receives valid keycode Ecore_Event_Key should have
an extended data member. This patch should be applied with server side patch.
@fix
Test Plan: run e wl server -> create wl client -> type keys
Reviewers: raster, devilhorns, zmike
CC: cedric
Differential Revision: https://phab.enlightenment.org/D712
const have been added in object parameter of two legacy APIs to fit
Eolian generated files.
Since these functions retrieve information from object, it is logic that
the object would be const.
The first object that we generate with Eolian is Evas_Line, as it is a
simple one.
Two files are generated during build:
- the .eo.c contains the APIs definitions invoking Eo, the Eo functions
extracting the parameters and calling the hand written functions and
Eo structures to define the objects. These hand written functions are
located in e.g evas_object_line.c.
- the .eo.h contains the APIs and Eo prototyes.
We will continue with the other objects. If you note something wrong,
please update us asap:
daniel.zaoui@samsung.comyossi.kantor@samsung.com
In Doxygen format, write the reference documentation for the filters.
It will contain a few examples only, should serve more as a reference
just like edcref.
This is for the script language itself, not for the Eo APIs or the
internal APIs (those are already documented).
We need a function in DnD for the overlapping feature to retrieve all
the objects at a specific position.
A private function exists in Evas (evas_event_objects_event_list) for
that purpose.
We need an access to this function for Elementary but we don't
want the is_frozen flag to be checked.
Wayland subsurfaces can be used as video surfaces too, similarly to
Ecore_X windows. However, they support a different set of features. Some
of them, like subsurface clipping and scaling, might be added in the
future, but so far we must work with what we have.
This commit allows to set an enum bitfield to the Video_Surface, with
the default value being one that will keep the same behavior as before,
for Ecore_X window. Thus, backward compatibility should not be broken.
It's possible to inform Evas that the surface in question is not able to
resize or scale, or that it's above or below the original canvas
surface. This allows Evas to show the surface itself, or use a buffer of
pixels instead, when the capabilities are not available.
This reverts commit 1714fe93f4.
We actually want this type, it makes things clearer.
Conflicts:
src/tests/eo/function_overrides/function_overrides_inherit2.c
src/tests/eo/function_overrides/function_overrides_simple.c
src/tests/eo/suite/eo_test_class_simple.c
NOTE: I am tempted to mark evas_object_memfile_set() as deprecated due
to the forced memcpy it introduced and the fact that it is now a 3 lines
of code to do the same in a more efficient way.
This function should be used internally by the input system
(Ecore_Evas_Input) to feed Evas with move events. The x,y event info is
relative to the base of the window/surface, instead of the 0,0 of the
canvas.
This case only happens for now under Wayland, where the 0,0 of the
canvas is translated due to the window decorations that are drawn by the
client.
Now, Evas.h includes three new files:
- Evas_Eo.h: Eo API functions (functions defines, enums, base id).
- Evas_Legacy.h: contains the API functions related to objects
- Evas_Common.h: common data (structs, enums...) +
functions not related to objects.
This phase is needed for the EFL 1.8 release to disable Eo APIs if we
consider it is not enough mature to be used by applications.