will be used to handle i18n for lua files in EFL (because only gettext 0.18.3+ supports Lua) and it'll be usable standalone too, it will also be able of handling more things than lua support in xgettext does (e.g. concatenated string literals will be considered one string)
Elua is a LuaJIT based runtime for the EFL meant to provide facilities for rapid application development. The name is temporary. The EFL bindings will be generated with Eolian. @feature
This patch:
- removes the @def from Doxygen, as it is not correct for API
functions.
- fixes the generation of class comments. When no class description is
supplied, no comment should be added.
place.
Instead of having the calculation (class name + function name + set/get)
in many places in the code, it is now in one place and accessible via a
function environment structure.
Eo.h depends on things that are generated by normal Eolian, and because Eolian C++
is generating code pre-build (WHY THE FUCK???), the dependencies are missing.
This removes the stupid include, but a more proper fix would be to move eolian_cxx
to be part of the build process and not pre-build.
In this case, the section 'implements' contains bad information about the
function to override. If the first (at least) function is correct, it
will never fail but use the last correct information retrieved from the
database.
The patch fixes it by checking the result of the database function
eolian_implement_information_get.
@fix
The function eolian_implement_information_get was returning strings for
the class and the function. It was written in this way at the beginning
because it was not needed to verify the correctness of the class and
the function.
Now that we have the namespace feature, this function must check it,
meaning that the class and the function are now known.
So we can return them instead of returning the strings.
The generators had to find the class from the classname. It is no more
needed.
The C++ generator has been adapted to this new API.
To reduce the invocations to strings conversions, we store the
classname, the Eo prefix in upper and lower cases in global variables.
The problem comes when we have to handle overriding functions. A lot of
conflicts between class base and class inheriting can happen.
The chosen solution is to create independent environments storing the
converted strings.
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
Summary:
This patch fixes T1226 by adding a Makefile.examples to
examples/eolian_cxx. It also fixes a bug in bin/eolian_cxx: the
include paths were not being correctly generated for directories
outside EFL tree.
Reviewers: cedric, smohanty, stefan_schmidt, stefan
CC: uartie, wayland-efl, felipealmeida, raster, woohyun, cedric
Maniphest Tasks: T1226
Differential Revision: https://phab.enlightenment.org/D824
Signed-off-by: Cedric Bail <cedric.bail@free.fr>
Since there was a bug in Eolian (Spank on you Savio that you didn't tell
me :-)), the cxx generator needed some workaround that is no more
mandatory now.
Summary:
Fixed distcheck for Eolian C++. Made the generated files as
nodist so it doesn't get picked up for generation way too
early.
Reviewers: cedric, seoz
CC: cedric
Maniphest Tasks: T1220
Differential Revision: https://phab.enlightenment.org/D820
Signed-off-by: Cedric Bail <cedric.bail@free.fr>
Summary:
This patch adds 'eolian_cxx' -- a C++ bindings generator --
to the EFL tree. Eolian Cxx uses Eolian API to read .eo files and generate
.eo.hh. It relies/depends on Eo Cxx and Eina Cxx (both non-generated
bindings).
src/bin/eolian_cxx: The eolian_cxx program.
src/lib/eolian_cxx: A header-only library that implements the C++ code
generation that binds the .eo classes.
=Examples=
src/examples/eolian_cxx/eolian_cxx_simple_01.cc: The simplest example,
it just uses some "dummy" generated C++ classes.
src/examples/eolian_cxx/eolian_cxx_inherit_01.cc: Illustrates how
pure C++ classes inherit from .eo generated classes.
src/examples/evas/evas_cxx_rectangle.cc: More realistic example using
the generated bindings Evas Cxx. Still a bit shallow because we don't
have full fledged .eo descriptions yet, but will be improved.
=Important=
The generated code is not supported and not a stable API/ABI. It is
here to gather people interest and get review before we set things in
stone for release 1.11.
@feature
Reviewers: cedric, smohanty, raster, stefan_schmidt
CC: felipealmeida, JackDanielZ, cedric, stefan
Differential Revision: https://phab.enlightenment.org/D805
Signed-off-by: Cedric Bail <cedric.bail@free.fr>
this was making syntax errors much harder to debug and only served the purpose of further enabling shitty, nonconformant edc creating. removing now before it becomes an api break
Before this change, all the .eo files of the directories given with -I
option were parsed. Most of this information was not necessary at all,
since only the classes belonging to the inheritance of the class given
as parameter were needed.
Now, during the parsing of the given class, the inherits classes are
searched and parsed.
A condition is needed to make it work well. To find a filename for a
class, we consider the lowercase of the class name as the filename we
have to parse.
e.g, Elm_Button -> elm_button -> elm_button.eo
It considerably reduces the generation time.
A fix in the tests was needed.
this is enabled for all scripts within a group, and it should only be used if you:
1) know what you are doing
2) know why this is unsafe (T905)
@feature
this allows for program.source to be omitted 99% of the time since most sources in an application/library will be the same within a single group
@feature
this allows any number of parts/programs to be added by name into a logical grouping which can then be referenced inside a program.
eg.
before
------
program { signal: XYZ; source: 123;
action: STATE_SET "default";
targets: "sup" "dawg" "parts" "up" "in" "dis" "progrizzle";
}
program { signal: ABC; source: 123;
action: STATE_SET "notdefault";
targets: "sup" "dawg" "parts" "up" "in" "dis" "progrizzle" "tooizzle";
}
======
after
------
target_group: "default" "sup" "dawg" "parts" "up" "in" "dis" "progrizzle";
program { signal: XYZ; source: 123;
action: STATE_SET "default";
group: "default";
}
program { signal: ABC; source: 123;
action: STATE_SET "notdefault";
group: "default";
target: "tooizzle";
}
@feature
in today's modern world of fast-paced, HTML5-driven, C++-riddled
development, nobody wants to spend hours typing out long words like
"description" or "mouse_events" or "name". there's no time for it
and certainly nobody is going to allocate budget for this sort of
keyboard-related nonsense.
enter lazEDC: the solution for edje-loving keyboard jockeys everywhere.
by breaking the parser of edje_cc with the strength of 10 frenchmen,
new, shorter keywords such as "nomouse" can be used in place of lengthy,
rambling statements like "mouse_events: 0", and things like
part { name: "clip"; type: RECT; description { state: "default" 0.0; }}
can now be written as
rect { "clip"; }
with the exact same effect.
initial tests show that complex and terrible edc files such as the infamous
"genlist.edc" can be reduced in size by over 15% using these new features.
see edcref for docs, and genlist.edc for examples
@feature
@awesome
partly revert adcc323291 as the default
ellipsis value was 0 as per the document, and must stay, as changing
this breaks edc descirptions as now text is no longer ellipsised by
default. this ACTUALLY broke titlebars on the default theme - just
have a title that is too long and see how it no longer goes:
This is a title he...
it instead covers the screen for as long as the title is.
if you want -1 for ellipsis... then set it. :)
what a huge, colossal cock-up of a clusterfuck. it's a good thing nobody ever uses ellipses or edje. otherwise we'd probably get complaints about this kind of thing.
Quality should not default to 100 unless specified in the
command line. In particular, we don't want to save ETC1 at
high quality by default since it can take hours (literally).
Add a new flag in EDC files to specify ETC1 compression
should be enabled. It follows the same rules as the
current LOSSY flag for JPEG compression.
@feature
There were a few critical issues:
- Invalid pointer arithmetics on the input data (char vs. int)
- Invalid logic in the pixel duplication code
All of these due to bad copy and paste :(
Also, use LZ4HC instead of LZ4 when compression is enabled.
ETC1 encoding is so damn slow you won't see the difference between
LZ4 and LZ4HC compression times.
This patch adds support for protected functions.
In the .eo file, the scope (public by default) has to be added before
the function name e.g:
protected foo ...
To access the protected APIs, #define (CLASS)_PROTECTED is needed e.g:
#define ELM_BUTTON_PROTECTED
For new classes that don't need legacy, instead of setting legacy null
for all the functions, legacy_prefix can be set to "null" to not
generate legacy.
However, if, for example, only one function among 50 need legacy, you
can specify it by setting for this function the legacy token.
After doing some edje_edit manipulations there was a problem that
after edje_decc of changed EDJ file it wasnt able to compile again, because some of scripts
weren't inherited.
The problem was in Code and Code_Script structure.
There is "shared" ("script") field and "original" field that contained a string with embryo script code.
After inheriting whole group, "original" field wasn't copied, so it wasn't able to write
the script into resulted EDJ file (look at edje_cc_out:1407).
@fix
Reviewers: cedric, seoz, raster
Reviewed By: cedric
CC: reutskiy.v.v, cedric
Differential Revision: https://phab.enlightenment.org/D671
Signed-off-by: Cedric BAIL <cedric.bail@free.fr>
previously we allowed users to not specify the state names for non-default description states. this guaranteed crazy behavior during inheritance since it was impossible to properly reference such states.
For get properties, if only one parameter is given, the generator sets this one as return type.
There are cases where this parameter must stay a parameter (legacy API).
For example, elm_thumb_compress_get must be like:
void elm_thumb_compress_get(const Eo *obj, int *compress).
Eolian was generating the function as:
int elm_thumb_compress_get(const Eo *obj);
By setting "return void;" in the .eo file, you force the function to
return void.
When a property needs be defined as virtual pure, its type could not be
given.
It means that, even it was explicit that e.g only the get property if
virtual pure, both (set and get) were considered as virtual pure.
@fix
Daniel Kolesa
Daniel Kolesa
Daniel Zaoui
Guillaume Friloux
Tom Hacohen
ChunEon Park
Mike Blumenkrantz
Felipe Magno de Almeida
Savio Sena
bluezery
Carsten Haitzler
Yossi Kantor
Jean-Philippe Andre
zmike
Cedric BAIL
Vorobiov Vitalii
Ryuan Choi