Units are Eolian files (eo/eot). Each unit contains information
about its class, dependencies, variables and types. This allows
for saner checking to be done.
If atomic support is disabled (via kernel or env var), then we do not
need to fill device atomic state as it will not be used anyway.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
If atomic support is not enabled (kernel or env var), then we should
not be filling in output atomic state
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This 'return' statement here is just useless as the code can fall
through and the function will return 0 anwyay.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Summary:
fix wrong initial value for ELM_PHOTOCAM_ZOOM_MODE_AUTO_FILL mode
@fix
Test Plan:
1. set zoom mode of photocam to ELM_PHOTOCAM_ZOOM_MODE_AUTO_FILL in text_photocam.c example
2. run elementary_test -to photocam
3. check it is working well
Reviewers: jpeg, cedric, raster, Hermet, singh.amitesh
Reviewed By: singh.amitesh
Differential Revision: https://phab.enlightenment.org/D4921
Summary:
map_surface does not redraw in below case.
1) parent and child are smart object and has map.
3) drawing objects.
4) apply new map to child object.
Test Plan: sample code
Reviewers: jpeg, cedric, jypark
Differential Revision: https://phab.enlightenment.org/D4889
Summary:
If multi selection have 0 column and delete the selection, 0 + 1 column also
deleted
This fix that bug.
Also, remove needless code.
Test Plan:
1. select multi line with 0 column.
2. delete the selection
Reviewers: ajwillia.ms
Reviewed By: ajwillia.ms
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4922
This implements edje_object_part_external_object_get() using
efl_content_get() on the part object. Note that there are now
two ways to call APIs on the external part:
- direct call to the efl_part() as if it was the object itself
(implemented by composition),
- get a handle with efl_content_get(efl_part()) and manipulate
it directly (it is the real object).
Do we need this? Do we need the composition trick? Should we have
only one of those solutions implemented?
This effectively replaces edje_object_part_external_object_get
and allows all function calls except those from Efl.Object.
Is this good enough? Or do we need access to the real object?
This adds a new class: Efl.Canvas.Layout.External.
I hate this long name...
This class represents an external part, and for now only
supports param_set/get as well as param_type_get. For now
param_type_get() still returns an Edje_External_Param_Type and
not another more generic type.
TODO: enumerate choices, return object, return content
Set this env var to "300 es" to test GLSL 300 ES as shader
version. This is for brokenshakles.
Example:
export EVAS_GL_GET_PROGRAM_BINARY=0
export EVAS_GL_SHADER_GLSL_VERSION="300 es"
export ELM_ACCEL=gl
elementary_test
Changing ck_assert_ptr_nonnull() to ck_assert_ptr_ne() in order to
require "only" check >= 0.9.10. ck_assert_ptr_nonnull() was
introduced in 0.11.0. ck_assert_ptr_ne() is already used a lot
in the test suite so a recent version of check is required.
Original patch by Jinwoo Shin:
If edje has multiple levels of child group,
edje_object_message_signal_process cannot process message on
child group. To cover that, it needs to add new API which
traverses its hierarchy and process messages.
@feature
Signed-off-by: jinwoo.shin <jw0227.shin@samsung.com>
Differential Revision: https://phab.enlightenment.org/D4914
This makes it work like C++ dynamic_cast<> operator, so that
the return value will be NULL if the object is not an instance
of the given class.
In case of efl_super() we don't do it as efl_super is used A LOT
inside EFL itself (all constructors & destructors, for a start)
and efl_isa is in fact a bit expensive. efl_cast isn't really used
and is intended to be something like dynamic_cast.
For @cedric :)
This refactors even more the edje part eo internals. But now
common part APIs can easily be implemented in edje_part.c
The API now looks like:
efl_gfx_geometry_get(efl_part(edje, "part"), &x, &y, &w, &h)
1. Make internal part "real_part_set" an internal function (EO)
2. Use a common class rather than an interface:
- Cost: 1 extra call to efl_data_scope_get() as we don't have
the data inside the EO function call implementation.
- Gain: Ability to implement common code, such as part_geometry_get
Ooooh. This one might be controversial, as some apps definitely
use the function. But it is so easily abused. For our EO API
we are trying to not expose any internal object, as this prevents
us from making changes to the internal behaviour and structure.
All the features that this API provided should be limited to
read-only access to the internal object. In order to replace
this, we will have to return an Efl.Part object that implements
all those APIs: geometry_get, visibility_get, etc...
Most of the values were the same, with edje having just a couple
more error codes.
Not entirely sure the prefix Efl.Image is correct for this type.
Maybe just Efl.Load.Error?