The elput library is an efl abstraction for the libinput library which
can be used by various other subsystems (ecore_fb, ecore_drm, etc) to
handle interfacing with libinput without having to duplicate the code
in each subsystem.
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
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:
http://www.linuxjournal.com/article/6060
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.
Fixes T3386
Summary:
elocation should be included before elementary otherwise 'make install'
will fail on clean instalation
Test Plan: make uninstall && make install
Reviewers: raster, tasn, stefan_schmidt, cedric
Reviewed By: cedric
Subscribers: reutskiy.v.v, jpeg
Differential Revision: https://phab.enlightenment.org/D3832
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
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
$ 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.
@feature
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.
Chris Michael
Cedric BAIL
Stefan Schmidt
Andrii Kroitor
Tom Hacohen
Srivardhan Hebbar
Felipe Magno de Almeida
Chris Michael
Seunghun Lee
Daniel Kolesa
Stefan Schmidt
kabeer khan
Larry Jr
Cedric BAIL
Daniel Kolesa
Vincent Torri
Savio Sena
Daniel Kolesa
Guillaume Friloux