|Age||Commit message (Collapse)||Author|
So far this was protected behind ifdef EO_API_SUPPORT. It also
was not used internally. Dropping this before the release, since
we will soon have a (hopefully) better solution to handle various
This removes the mixin functions and uses static inline functions
instead. Much cleaner, looks the same to C devs.
This is to port elm_config to EO APIs.
The current implementation relies on the legacy API, by
simply forwarding calls.
The new API is simply efl_config_set("config_name", value)
where value is an Eina_Value (aka. generic_value).
The C interface proposes a few helpers like config_int_set,
Unfortunately at the moment, not all config options are
supported, as some rely on more complex types:
- color class and multiple arguments
- unset functions
Profiles are also not handled at this point.
We hit another argument too long error with CLEANFILES. Moving the generated
files for js and lua into separated variables and cleaning them manually fixes
This renames it to Efl.Text.Bidirectional_Type.
Not sure this is a good name for this interface, but it
definitely doesn't belong inside lib/evas/
Thanks Jiyoun for the question / report :)
This is again to avoid the "Argument list too long" error we are hitting more and
more now. Given we just merged elementary, emotion generic players, evas generic
loaders and elm_code it is not surprising we are hitting it again.
This time the number of files being hold in DISTFILES has just grown to big so a
make dist was no longer possible. If one looks at what the DISTFILES variable
from automake holds you can image it grows a lot with all the source files plus
generated files we have in tree now.
DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
To cut off a big chunk but still keep all the other automagic in place for
SOURCE files I went and renamed the EXTRA_DIST in src/ to EXTRA_DIST2 and handle
the files in a dist-hook now.
Another thing to note here is that this also only happens as we have the one big
Makefile with includes. If we go back to per directory Makefiles this problem
should vanish as well. In any case we need a solution for 1.18 now and this is
what I have to offer. If you have a cleaner solution in mind feel welcome to
test it out and if everything we need keeps working (make, make examples,
make check, make benchmark, make dist and make distcheck) go ahead.
create Efl.Gfx.Size.Hint skeletton and change elm_win eo.
remove size_step and size_base API from elm_win
and inherit from Efl.Gfx.Size.hint
elm_win have three feature releated with screen.
so create efl_screen interface, and elm_win implement that interface
This is going back to the same idea as legacy. We will have
events such as:
- cancel ("new" - very rare)
Now the question is whether/how we should divide "multi" events
which start from the 2nd finger from standard mouse events. The first
multitouch finger should by default look like a mouse event.
This moves Efl.Pointer.Event back to Evas. Originally I wanted
to share this class with Ecore but eventually I didn't need to
do so, since only ecore_evas (which depends on evas) really needs
access to these.
The internal data struct is not moved out of efl (yet?)
Moving enums to Efl renames them but keeps the value the same.
This object is the data carried over in an event data pointer.
The private data should be accessible by Ecore and Evas, but
not externally. This means we should be able to easily extend
the feature set, adding more and more information, without
breaking API / ABI.
Also, this should allow applications to create fake input
events easily without exposing our internal structures, or
functions with more and more parameters (such as feed multi).
This is only a storage class, shouldn't contain any logic.
In the future, some logic may be added for gestures support
for instance, or input smoothing / resampling (eg. if input
frequency is 90Hz and screen refresh rate is 60Hz).
The aim is to replace:
We might want to also support Axis, Gestures, etc... with the
same model or even same storage class.
So, this is not a very clean solution, but this mostly
makes Evas_Device an Eo object of class Efl.Input.Device.
Since evas_device relies on some Evas knowledge (evas
callbacks, canvas private data), it can't be fully moved
Making the input device an interface rather than a class
was also not a great solution, as the goal is to share
the data structure around EFL internals (Ecore and Evas).
This should now fix the part API usage once and for all.
EFL should have no part name in any of its APIs beyond
the Efl.Part interface.
Part proxy objects (may be real objects) have a lifetime
of only one function call, in a fashion similar to eo_super.
Moved all generation to a single Makefile_Cxx.am file instead of
throughout the whole project. And fixed C++ generation on Elementary
after elm merge.
Added common interface for flipselector and spinner.
Implemented APIs of spinner like min_max_set, step_set, value_set etc in flipselector.
Test Plan: elementary_test
Reviewers: raster, jpeg, singh.amitesh, woohyun, SanghyeonLee, cedric
Reviewed By: cedric
Differential Revision: https://phab.enlightenment.org/D3905
Signed-off-by: Cedric Bail <email@example.com>
This removes Efl.Pack_Named which had a terrible name,
removes Elm.Container which should have been renamed
Efl.Ui.Container anyway, and introduces an interface
The hierarchy tree is now changed as objects don't inherit
from Efl.Container (it's an interface, not a regular class)
but only implement it. Obviously it is very easy to
reintroduce an Efl.Ui.Container parent class if we need it,
but I guess it should have some actual logic. It's basically
part of what Elm.Widget already does.
Some function names have been modified to look better in C
with the efl_content prefix.
- Children are now contents
- Efl.Pack_Layout is now a separate class and
- Removed dumb class Efl.Pack_Item
- Updated docs
- Added pack_ or grid_ prefixes to some methods
So, since we don't have function pointers, all the solutions
to reimplementing the layout function are quite convoluted:
1. use events
2. reimplement layout func
3. use an extra object
4. use a generic class (non instanciated)
Promises don't apply here (layout will run multiple times).
1. Multiple event callbacks will be called, resulting in
potential performance impact, extra events, etc...
Also, there is no way to define standard implementations
that would be provided by the framework.
2. Reimplementation of a function requires extra EO work
(create an EO class, etc...), doesn't allow on-the-fly
change of the layout method.
3. Probably the best solution is to have an object implementing
the layout. But this means creating an extra object along
with the container.
4. To avoid the extra object, use a class, and reimplement
a @class function. This unfortunately requires extra
Solution 4. has been selected, but it's not very nice...
I chose the name "pack" instead of containers because it
is shorter, and allows out-of-the-box short C names like
efl_pack_end() instead of efl_container_pack_end().
All Pack interfaces will use the same efl_pack eo prefix.
This is still work in progress.
Efl.Flip is now the enum, the interface is Flipable.
We could even use names like Efl.IFlip a la Java.
eo_prefix is used to have pretty names in C. legacy: null
is removed from the enums. orient_x0 is removed and only
defined in C with #define
Implement common interface efl_ui_progress and inherit slider and progressbar from common interface.
Currently legacy APIs will also call interface functions and later it can be deprecated.
This interface will be moved to EFL in src/lib/efl/interfaces when elementary is merged into efl.
elementary_test -to 'slider'
elementary_test -to 'progressbar'
Reviewers: singh.amitesh, raster, tasn, felipealmeida, woohyun, cedric, jpeg
Subscribers: saurabhbunty, alok25
Differential Revision: https://phab.enlightenment.org/D3759
Added flip and orientation interface and used them in evas_image.
Removed efl_image_orientation_set API and used efl_orientation_set and efl_flip_set API.
In implementation part, converted enums back and forth in order to keep current implementation as it is.
Test Plan: src/examples/evas/evas-images5.c
Reviewers: singh.amitesh, raster, tasn, herdsman, woohyun, cedric, felipealmeida, jpeg
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3844
this adds a core vpath subsystem to efl that allows paths like:
etc. to be translated/looked up. it is desitgned to be async and call
event callbacks when ready. the reason for this complexity is fo in
future also handle:
This reverts commit bc238146146d2bdd6a36e0aa31b83f9ce59ac98b.
This reverts commit 5e9d838e60809a7dede3e1179ca35ccd02ea6d4d.
We have been putting the generated eo files and BUILT_SOURCES into CLEANFILES
several times. So far this have not been a real problem but with the elm merge
and more and more eo files showing up this did explode recently.
During make distcheck a lot of files kept being around and make complained about
them. It took some digging to find the arguments list to long error. If you want
details on this great limitation have a look here:
In our case we have been lucky enough that we just appened many files over and
over again. Not doing that solves the issue for now. My testing showed no
problems but if I missed something let me know.
This interface groups all low-level animated image functions.
- Rename to Efl.Image.Animated once eolian is fixed
- Fix mess with emile enum (loop_hint)
It has been decided that we would not use any namespace for interface
and they will sit in efl main namespace.
This patch doesn't correct the naming of the event has we don't have a
prefix for event. We do still have EFL_ANIMATOR_EVENT_ANIMATOR_TICK,
instead of a nicer EFL_EVENT_ANIMATOR_TICK.
Fix Efl.h include problem of the installed header "efl_types.eot.h".
Move efl_types.eot to src/lib/efl/interfaces to compile and install at
the same place of other Eolian-generated headers.
Test Plan: compile and test expedit
Reviewers: felipealmeida, stefan_schmidt, tasn, cedric, q66, JackDanielZ
Differential Revision: https://phab.enlightenment.org/D3670
Moved the Ecore.Time @extern struct to Efl lib and defined it as
specified in C specification for struct tm. Thus, bindings can be
automatically generated for where struct tm is used.
Cedrics original change made sure the file was actually dist_installed but
failed to be placed inthe correct inlucde folder and thus failed the elm build.
While raster fixed this he broke the distcheck build as the file was no longer
put into the tarball being marked as nodist.
This fix handles all the cases I tried in my testing here.
This create some possible naming clash and is why I come up with
efl_gfx_color*_type_set functions. We will have to think about this more
carefully as it makes sense to now pass this colors directly to our color
API. Ideally the default 8 bits interface would become just a convenience
wrapper around the more complex possibility.
To configure efl sources with bindings to use in nodejs add ––with-js=nodejs in configure flags to generate node files
$ configure --with-js=nodejs
and compile normally with:
$ make install
To use, you have to require efl:
efl = require('efl')
The bindings is divided in two parts: generated and manually
written. The generation uses the Eolian library for parsing Eo files
and generate C++ code that is compiled against V8 interpreter library
to create a efl.node file that can be required in a node.js instance.
Signed-off-by: Cedric BAIL <firstname.lastname@example.org>
Rename a few things:
- draw helper -> efl_draw
- Ector_Rop -> Efl.Gfx.Render_Op
- ECTOR_ bla bla -> DRAW_ bla bla (base pixel ops)
- ector_memfill -> draw_memset32 (and invert arg order to match memset)
The main rasterizer file is now draw.h in static_libs/draw
This is a non functional change, simple code refactor.
When src/bin/efl/ builds with [--with-tests=coverage], it fails to find gcov lib.
The gcov/lcov related options has to be passed when it is builded.
And it only contained in EFL_CFLAGS, EFL_LIBS.
Be sure the your enviroments to build src/bin/efl/.
1. Run ./autogen.sh --with-tests=coverage
2. make or make check
3. See the build errors.
Reviewers: raster, jpeg, cedric
Reviewed By: cedric
Differential Revision: https://phab.enlightenment.org/D3370
Signed-off-by: Cedric BAIL <email@example.com>