this massively improves edje performance when using groups, which previously would continue calculating their parts even when their parent object was hidden
CPU usage in my test case went from 20-30% to 1%.
@fix
When using -O2 or -O3, the Eina_Bool legacy_support (unsigned char) was
overriding the int eo_needed.
The result was a failure during options check:
Eo flag is not specified (use --eo). Aborting eo generation.
@fix
Until now, the functions giving access to class information were taking
the class name as parameter.
Except the fact that we needed to search into a hash table for the internal
class structure, no flexibility is possible.
This change consists in modifying most of the APIs using the class name
with a new Eolian_Class type and adapt the code of the C and C++
generators accordingly.
By using -gi option, the generator appends the functions that are
present into the given eo file and missing into the developer file
(given via -o option as an in/out file).
@feature
It includes parser updates, database fill and tests on basic and complex
types.
One can define types in this way:
type Evas_Coord: int; /* Simple type definition */
type List_Objects: Eina_List * <Eo *>;
@feature
Summary:
Sorry, last patch added the headers to the correct relative
location but replaced dist with nodist which is incorrect. nodist is
for generated headers only.
Reviewers: cedric, raster
Reviewed By: raster
CC: felipealmeida, smohanty, cedric
Differential Revision: https://phab.enlightenment.org/D898
Summary:
Mainly from the examples but also from libunibreak and tests/eet.
I'm not sure if it's really worth to remove warnings from the examples
-- because it adds pedantic-ness to something supposed to be didatic,
but I leave for you guys to judge.
Reviewers: tasn, cedric
CC: felipealmeida, raster, smohanty, cedric
Differential Revision: https://phab.enlightenment.org/D896
Signed-off-by: Cedric Bail <cedric.bail@free.fr>
Summary:
Vanish with these:
src/Makefile_Eolian_Helper.am:15: warning: '%'-style pattern rules are a GNU make extension
src/Makefile.am:36: 'src/Makefile_Eolian.am' included from here
src/Makefile_Eolian.am:42: 'src/Makefile_Eolian_Helper.am' included from here
src/Makefile_Eolian_Helper.am:18: warning: '%'-style pattern rules are a GNU make extension
src/Makefile.am:36: 'src/Makefile_Eolian.am' included from here
src/Makefile_Eolian.am:42: 'src/Makefile_Eolian_Helper.am' included from here
src/Makefile_Eolian_Helper.am:21: warning: '%'-style pattern rules are a GNU make extension
Reviewers: tasn, cedric
CC: JackDanielZ, smohanty, felipealmeida, raster, cedric
Differential Revision: https://phab.enlightenment.org/D894
Signed-off-by: Cedric Bail <cedric.bail@free.fr>
If classes A and B are stored in a same file, when A inherits from B,
and A needs to be generated, the generator, even if B is parsed, will
not search the class in the database but will look for some b.eo.
This patch fixes that issue by checking the existence of the classes
into the database before looking for a corresponding file.
Summary:
text_props.len indicates visual length from harfbuzz logic when it is available.
But, input pram "idx" is logical length. So, ellipsis works abnormally in some case.
@fix
Test Plan: D870
Reviewers: tasn, woohyun
CC: cedric, herdsman
Differential Revision: https://phab.enlightenment.org/D871
Summary:
Some fonts has combination information for "ff".
When harfbuzz is enabled with the font, evas text ellipsis logic can be broken.
Reviewers: tasn, woohyun, cedric
Reviewed By: tasn
CC: cedric, herdsman
Differential Revision: https://phab.enlightenment.org/D870
Some comment/commit message improvements by TAsn.
Match function names when the API pointer is out of range.
Reviewed by TAsn and modified according to his comments :)
Differential Revision: https://phab.enlightenment.org/D876
Summary:
the draggable.event field (in edje) is pointing on the id of the part it is assigned to.
The main problem is about deleting parts.
After part being deleted, all other parts (that are below the deleted part) have their id shifted,
but event doesnt shift.
For example,
1) draggable.event at some part pointing at part with id=7,
2) some other part is being deleted
3) part with id=7 have new id now (id=6)
4) draggable.event DOESN'T change it's pointer and still points at part with id=7 (which is now has id=6)
5) if there is no parts with id=7 anymore, then it could give you SEGFAULT someday (or not, depending on luck).
This commit contains next changes:
1) after deleting part, draggable.event also shifts (if required)
2) after deleting part that is being pointed with event by someone, it will remove all event points at it
@fix
Reviewers: cedric, raster, seoz
CC: reutskiy.v.v, cedric
Differential Revision: https://phab.enlightenment.org/D878
Signed-off-by: Cedric Bail <cedric.bail@free.fr>
ChunEon Park
Tom Hacohen
Oleksandr Shcherbina
Stefan Schmidt
Daniel Zaoui
Jean-Philippe Andre
Matvey Konovalov
maxerba
Mike Blumenkrantz
Carsten Haitzler
zmike
Savio Sena
Savio Sena
Youngbok Shin
Vorobiov Vitalii
Shinwoo Kim
