Summary:
This lib would be used in efl_network_websocket.
Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com>
Reviewers: cedric
Reviewed By: cedric
Differential Revision: https://phab.enlightenment.org/D3244
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
this fixes warnings about no efreet dbus session bus in non session
environments as brought up on the mailing lists with:
Subject: Re: [E-devel] [EGIT] [core/efl] master 01/01: edje: unset
efreet cache update flag to prevent dbus connections
this moves all of efreetd client and server to ecore ipc, with client
auto-launching efreetd if not found as a service and trying for up to
500ms to connect. efreetd times out on last connection or no
connections after 10sec so it wont hang around forever if not in use.
it seems to work in my testing, so let me know if there is an issue.
@fix
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
This reverts commit 35119e7bfd.
Reverted to bring make check back in a working state. Also the way we
want to handle a more modular testing needs discussion.
Currently make check runs tests of whole EFL.Enabled running
of tests of individual modules by make check-<modulename>
Signed-off-by: kabeer khan <kabeer.khan@samsung.com>
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
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.
Summary: Added cmake config files for Eio
Test Plan: install it and test it with a app with needs eio
Reviewers: cedric, tasn
Reviewed By: tasn
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D2079
While we used different variation of mkdir -p all over we also had spots
where we did not use the option. This is one step in trying to make our
build system ready for parallel install. Using something like -j 10 even
for the install should help to speed up our jenkins jobs as well as distcheck.
Reverts 21da4a5454.
It is needed to generate Makevars in-tree even when building out-of-tree because of
how Autotools work. However, distcheck doesn't properly remove the Makevars file in
the generated distdir and makes po/ read only, preventing the build system from
generating an up-to-date version of Makevars. This commit adds the required hooks
needed to fix this behavior.
If you did do a make clean, then you couldn't do a make afterward. Reason
was that po/Makevars is generated by configure and not Makefile. So it can
only be cleaned with make distclean and not make clean.
This reverts commit 842e8e9fa0.
Scratching my head over this for a long time now. It sneaked in when
jenkins nightly builds which generates coverage reports was broken
due to newer gettext error handling. After that was fixed the build
kept being broken but now in coverage generation.
Finnaly found this change. Why was it done? Did you actually test it?
Coverage generation worked fine on my local system as well as on
jenkins when I worked on this. If it is broken for you we might need
to have another look, but not by breaking jenkins.
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>
Mixing up the new eolian test with its generated eo_lexer code and a new
version of lcov like 1.10. It works fine with lcov 1.6.
The problem is that this combination somhow triggers a wrong file path
with filename NONE. It was only triggered when adding the eolian test
suite so its a combination here.
For now we use this bandaid to remove the broken files. Need to find a
way to report this to lcov upstream.
If the dbus service contains SystemdService entry and the dbus-daemon
is started with --systemd-activation, then requests for services on
the user session bus will be handled by systemd, creating cgroups and
being handled as native systemd services of Type=dbus.
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>
Srivardhan Hebbar
Nicolas Aguirre
Florent Revest
ChunEon Park
Seunghun Lee
Carsten Haitzler
Seunghun Lee
kabeer khan
Stefan Schmidt
Felipe Magno de Almeida
Larry Jr
Jean-Philippe Andre
Cedric BAIL
Marcel Hollerbach
Daniel Kolesa
Tom Hacohen
Savio Sena
Cedric BAIL
Vincent Torri
Daniel Zaoui
Gustavo Sverzut Barbieri
Chris Michael
Chris Michael