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
This step is needed to clean the code and to prepare the integration of
Eo2 inside Eolian.
Except the eo_do invocation, there is no reason why legacy has to know
about Eo.
this is just some syntax shortening for program.after which causes program.action and program.script to create a new program and automatically chain it within the sequence{} block
recursive sequences not currently allowed/planned (don't be insane)
@feature
Summary:
...cannot encode those things into edje.
In our case, we need vibration when longpressed. But those files are not
audio or image and cannot be encoded into edje. Also, this library is not
opensource so should not be linked directly with edje.
So we should call vibration API by using this plug-in.
Reviewers: raster, cedric, seoz, Hermet
CC: cedric
Differential Revision: https://phab.enlightenment.org/D588
Now, it is possible to assign a default return value for a
method/property.
It will be used in case the function invocation makes issues, e.g eo_do
failing to find the function...
Before eo_do invocation, generated legacy functions returning a value
initialize it to 0.
This change is needed in the case that eo_do fails to find some
function, which leads to an unitialized value and behavior.
When a parameter of a property is const for get but not for set, the
.eo file indicates it by setting a flag 'const' for this parameter.
The generation was checking this flag for C files generation but not for
H files.
- Remove space between type and variable if a star is present.
- Initialize return value to NULL before eo_do. It is needed in case the
eo_do invocation fails (NULL object...).
- Add const to the internal return value if needed.
When an Eo operation returns a value, this one is stored in the last
parameter as an out parameter.
In case the caller doesn't set a pointer there, the storing will be done
in a NULL pointer and will bring to a segfault.
The generator has been modified to handle this case. Now, if the ret
pointer is NULL, the value will not be returned.
You can add in the .eo file the eo_prefix:... and data:... in case
you want to override respectively the Eo prefix and the data type.
If "data: null" is used, no data type will be added.
When legacy is specified in the .eo file, the generator was adding the
property/method name after the legacy name.
So if you have 'legacy evas_object_textblock_clear_all' for clear method,
it was adding the function evas_object_textblock_clear_all_clear.
- Added Doxygen description to parameters and return
- Added default description for parameters
- Return type needs to be after all the other parameters
- Better handling of stars for pointers: try to figure if a space is
needed between the type and the variable (e.g int *a / int a)
This tool lets you just open an eet file for editing directly,
by wrapping around 'eet' and the preferred editor defined in the env var
'EDITOR'.
@feature
@ferature: This adds code for the ecore-drm auth process to open
restricted inputs/cards/etc by the user.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Eina_File line iterator does give the length of the line including the '\n'.
We did previously ignore that and passed the '\n' down to eio_monitor. Obviously
it would fail to monitor a PATH that finished with a '\n' and edje_watch did
stop working. I guess nobody did any real testing with edje watch in the past
year.
@fix
1) Include files now have include guards
2) --gh option generates legacy header with --legacy flag and eo header
without --legacy flag
3) EOLIAN keyword is introduced to mark functions used by generated
file.
4) * for comments when comment text is empty
Now --gh/--gc don't require an additional argument.
If eolian_gen is called with --gc and some file.eo, the tool will
generate file.eo.c.
You can force another filename by using the -o with an argument.
Moreover, logging has been added to the generator.
Imported by Tom, from the eolian repo which was written by:
Daniel Zaoui <daniel.zaoui@samsung.com>
Yakov Goldberg <yakov.g@samsung.com>
Yossi Kantor <yossi.kantor@samsung.com>
Savio Sena <savio@expertisesolutions.com.br>
Jérémy Zurcher <jeremy@asynk.ch>
Signed-off-by: Tom Hacohen <tom@stosb.com>
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
Tae-Hwan Kim
Stefan Schmidt
Chris Michael
Cedric Bail