Summary:
Ecore_Buffer is abstraction of graphic buffer.
it supports backend of shm, x11_dri2 and x11_dri3 for now,
and this library also provides method to share buffers between processes.
Ecore_Buffer_Provider and Ecore_Buffer_Consumer is for this, sharing buffer.
provider draws something in to Ecore_Buffer, and consumer receives and displays it.
the binary, bq_mgr is a connection maker for buffer provider and consumer.
it can be included Enlightenment as a deamon later.
@feature
Test Plan:
1. Configure with --enable-ecore-buffer and --enable-always-build-examples to build examples.
2. Run bq_mgr, it connects consumer and provider.
3. Run ecore_buffer_provider_example and ecore_buffer_consumer_example
Reviewers: lsj119, gwanglim, cedric, zmike, jpeg, raster, devilhorns
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2197
We need to build everythign else before. Without this dep running check-build
as first target from a fresh build will fail due to wrong dependency handling
(like no eolian run over the eo files, etc)
Inspired by D2489 from Kabeer Khan.
This problem have been observed by Scimmia22 on the Arch builds as well as on
the jenkins wayland build job. While compiling works fine the relinking during
make install fails with ecore-drm linking does not find eeze or eldbus as its
deps. This only shows on systems with no efl installed, a build from scratch.
As far as I can see we have all dependencies set correctly in configure as
well as in the Makefile which are working fine even in highly parallel builds.
It was a bit surprising here to me that the include order is still important
with our correct dependencies. Autotools wisdom is welcome here to either
explain to me why this is needed or what the correct fix would be.
The includes all moved before Ecore_Evas because that would use ecore_drm if
enabled.
Fixes T2281
Idea for this library is to become a retained mode drawing library that use
Eo/Eolian for its API and take a lot of the good design from Enesim by
Jorge Zapata and Jose Gonzalez (http://enesim.org/).
The intent of Emile is to be the common layer for serialisation, compression
and ciphering. It will expose the library we currently use internally to an
easier use from the outside (like gcrypt and lz4). It should improve portability.
Instead of pushing JSON, XML and what's not to Eina, I do think that they will
fit better in Emile.
As for the naming of Emile, you will need to be French and say :
"Un quoi ?" "Un serializer !"
Regarding why it is put there in the stack. Right now there is two users of
compression (eet and terminology), two users of cipher library (eet and ecore_con)
and a few handful of user for serialization (eina, eet, efreet, ecore_con, ...).
So the choice was quite simple, it needed to be below Eet. Now it could have been
on top of Eo or integrated into Eina.
One of the use case I am thinking of, is to compress Eo object when a canvas get
hidden/minized. For that it require Eo to use that library and it can't be a higher
level object. And with current implementation of Eo it is perfectly possible to
implement such idea. So not at Eo level.
As for Eina, I am starting to think it is getting to much things in its namespace.
I do believe that infact Eina_Simple_XML and Eina_File should after all have landed
in their own library. That's why I am putting the current logic in a new library.
It is going to expand, I want it to provide an few SAX like parser for JSON,
Eet_Data and protobuf with also an API like Eet_Data to directly feed those value
into a C structure without using a DOM at all. It would also be the right place
to experiment and benchmark for a new Eet_Data format that could be more efficient
to use.
So at the end, and due to how I see things going and being used, I do think it
is better of in its own library.
While install-exec-hook gets normally executed after install and
thus we would have this we need to ensure it here when we want to
be safe regarding parallel install.
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