Elocation is meant as a convenience library to ease application developers
the usage of geo information in their apps. Adding a geo tag to a picture or
translating an address to a GPS position and show it on a map widget are just
some of the use cases.
In the beginning elocation will rely on the GeoClue1 DBus service. Supporting
the new GeoClue2 DBus service is planned and worked on. GeoClue offers
providers for various techniques to get hold off the current position. Ranging
from GeoIP over wifi and GSM cell location to GPS.
This has been developed a while ago and was living in my private dev space.
It is about time to move this into EFL and bring it forward.
The detection of the GeoClue service is being handled on runtime and no new
dependency is added due to this library.
@feature
The C++ examples were being added twice. So the make distclean was tried after the Makefile was already removed.
Removes the EXAMPLES_SUBDIRS redundancy for the C++ examples.
Summary:
Applications can:
void method_callback(void* data, const Eldbus_Service_Interface* iface,
const Eldbus_Message* message);
struct { ... } data_struct;
Eldbus_Method methods[] =
{
"method1", ELDBUS_ARGS("b", "bool"), ELDBUS_ARGS("b", "bool"), ELDBUS_METHOD_FLAG_HAS_DATA
, (Eldbus_Method_Cb)&method_callback, &data_struct
};
And method_callback will be called with data parameter pointing to data_struct global object.
Also, Eldbus-cxx supports registering an interface passing a lambda or
function object as method. For example:
edb::service_interface iface = edb::service_interface_register
(c, path, interface
, es::method("SendStringAndBool"
, [expected_string, expected_bool] (std::string const& n, bool b
, bool* out)
{
std::cout << "Running SendStringAndBool" << std::endl;
ck_assert(n == expected_string);
ck_assert(b == expected_bool);
*out = b;
return n;
}
, es::ins<std::string, bool>("string", "bool")
, es::outs<std::string, bool>("string", "bool")
)
);
When a request for "SendStringAndBool" with the proper signature is
called, executes the lambda and replies with the return value and
its bool* out parameter value.
Reviewers: cedric, woohyun, raster
CC: savio, cedric
Differential Revision: https://phab.enlightenment.org/D1052
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 allows people to disable the building of anything GUI related.
In my case, it is used for servers.
I encourage anyone that think they can do a better patch to improve it,
as i dislike having to add all those AM_CONDITIONAL().
Maybe the macros should be improved.
Summary:
Added HAVE_CXX11 guards to Makefile*.am files for C++ binding to avoid
compilation errors for examples when C++11 isn't supported. This also
disable installation of all EFL CXX pkgconfig files.
Reviewers: cedric, stefan, stefan_schmidt
CC: cedric, savio
Differential Revision: https://phab.enlightenment.org/D831
Signed-off-by: Cedric Bail <cedric.bail@free.fr>
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>
The first object that we generate with Eolian is Evas_Line, as it is a
simple one.
Two files are generated during build:
- the .eo.c contains the APIs definitions invoking Eo, the Eo functions
extracting the parameters and calling the hand written functions and
Eo structures to define the objects. These hand written functions are
located in e.g evas_object_line.c.
- the .eo.h contains the APIs and Eo prototyes.
We will continue with the other objects. If you note something wrong,
please update us asap:
daniel.zaoui@samsung.comyossi.kantor@samsung.com
The point of this binding is to enable the support for easy lambda for ecore function
that wont be using Eo. See the tests on how to use those.
Reviewers: cedric, raster
CC: savio, cedric
Differential Revision: https://phab.enlightenment.org/D582
Signed-off-by: Cedric Bail <cedric.bail@free.fr>
The goal of this library is to make the life of C++ developers easier
when having to manipulate Eina datatype by providing a layer to abstract
those data type in C++. Check examples for now. Documentation will come
soon, but we are pushing that rather sooner to get feedback on those bindings.
As you will notice, this library is just composed of headers. There is no .so
and we do think it is better this way. Reducing ABI and API stability issue for
applications developers who are the primary target of this binding.
Also please note that you will need to have C++11 to use this binding.
Signed-off-by: Cedric Bail <cedric.bail@free.fr>
it was failing:
- leaving missing objects (.edj, .la)
- eo was not building its examples automatically with --enable-always-build-examples
- make dist with '--enable-always-build-examples' was not including 'src/examples'
plus lots of ignored files due test changes.
SVN revision: 82894
Instead of just making our own "check-local" and calling the binaries
ourselves, just append them into "TESTS" variable. Then they run after
all check_PROGRAMS are compiled.
The reasons for changing are:
1) If we change the test and call "make check" the test is not
compiled again -- and the only way to compile it is to "make clean".
2) There's no need to reinvent the wheel here.
With a recent version of Automake, the test output is redirected to log
files. This is good but unexpected for whom was used to the previous
way. So, be warned.
SVN revision: 82841