| Age | Commit message (Collapse) | Author |
|---|
|
Destination of libefl_mono.dll is OS dependent, this was not translated
to efl-mono.pc.in. This commit fix this issue.
|
|
The C# bindings are built using the --enable-csharp-bindings (disabled
by default).
|
|
This reverts commit 482724d52aaebb21ebb228eead9ddc107b094780.
Sorry!!!
|
|
|
|
conflicts)"
This reverts commit 2cea85db388d34337676466ef7f50c22e685c7d0.
Their was a typo that I made during cleanup of the patch before pushing that I didn't
notice broke some stuff. But also you may have an old efl_general.h in your elementary
directory that is now being picked instead of the one provided by the tree.
|
|
Revert "elementary: currently double declare elm_init/shutdown."
This reverts commit 44bb0c18480f5094fcd0c8be93de87be5c1d78c5.
Revert "elementary: fix efl_ui_multibutton installed headers."
This reverts commit 32a213dc722be2bfec5fb2b513dd556cfb7e9f33.
Revert "elementary: introduce Efl_Ui.h."
This reverts commit df3d3f7334a79f1ab661b31787002f50af59b3f3.
Revert "ecore: do not display error message on cancel."
This reverts commit 99654b7cd29b418e0308be350c8d26208c0905a8.
Revert "efl: and don't forget to install the new dependencies."
This reverts commit 814ffb9b6bd50d498bfd98f4b8a75f1cad3cc0cf.
Revert "ecore: remove EFL_OBJECT_BETA as Efl_Core.h is for Efl new inerfaces."
This reverts commit 619d0f3cff023414feb8f2aaeebf468806c50b44.
Revert "ecore: move EAPI_MAIN from elementary to ecore."
This reverts commit e5d84da864214b9f772808040f22e1614889a25f.
as such commit e5d84da864214b9f772808040f22e1614889a25f starts the
breaking. enlightenment, terminologya and other apps can't compile
against that efl anymore. 619d0f3cff023414feb8f2aaeebf468806c50b44
then makes this even worse with even more header errors and undefined
types. on top of this df3d3f7334a79f1ab661b31787002f50af59b3f3 then
starts making elementary_test segfault when it runs. it wont even
start up.
asu such of these 7 commits in the first 4 (that are then relied on
later) 3 of these first 4 cause serious breakage. this simply is a
complete lack of testing changes, so i've rolled fl back to before
these things so it builds and works again and you can build against it.
PLEASE test these things. this looks ot me to be obviously a lack of
any testing... :(
|
|
|
|
The '-S' option lets you reverse that. But by default, most
people will want the prefix to be scanned for eo files.
|
|
|
|
gesture files are not found because the include path is not supplied by
pkg-config.
|
|
|
|
|
|
|
|
This backend has received no patch and maintenance from anyone who could
actually test it over the last few years. After talking with KaKaRoTo it
is best to remove it. If anyone want to take over its maintenance, you
are welcome to revert this patch.
|
|
|
|
as per mailing list discussion about dropping xcb support now. it
hasn't been complete for a long time, thus not recommented for being
turned on. as we are moving to a wayland world xcbmakes even less
sense. as agreed, time to clean up a bit and remove a distraction as
well as not well tested code. this also updates po's too.
@feature
|
|
@fix T4120
|
|
|
|
This new library is going to replace the existing Ecore_Drm. This will
refactor a lot of the code, bring improvements over the existing API,
and provide additional support for missing features.
@feature
Signed-off-by: Chris Michael <cpmichael@osg.samsung.com>
|
|
ignore a generated pc file.
|
|
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>
|
|
I added Efl.h to Ecore.h - because we really want to use efl
interfaces ... like everywhere. so add it to the link too.
|
|
T3397
|
|
|
|
T3361
|
|
|
|
|
|
EGL Fullscreen is a module intended to support many proprietary GL driver that come
with custom API to create framebuffer/window. This one is starting by covering Android
with libhybris/hwcomposer. Later on, it should be able to support easily the Raspberry Pi
driver.
At this moment this does not work properly. Activate it at your own risk ! Do not report
bug if you don't know what you are doing :-) A backend for Ecore_Evas will come later on
along with a patch for Ecore_FB to use libinput. Finally a few patch should hopefully
enable this backend to work and compile more easily (relying on proper header detection
and dlopen/dlsym for access to proprietary function).
You can read more about the goal of this patch by reading our wiki at :
https://phab.enlightenment.org/w/boot2efl/
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
|
|
Also fix spelling in .pc file
|
|
|
|
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
|
|
Signed-off-by: Chris Michael <cp.michael@samsung.com>
|
|
Signed-off-by: Chris Michael <cp.michael@samsung.com>
|
|
This reverts commit 3b2074aa710a095c2379702334bfa125bcc1990a.
|
|
|
|
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
|
|
@fix T2458
|
|
|
|
Otherwise, the elementary build is brocken while crosscompiling since
"pkg-config --variable=eolian_flags eo evas edje ecore efl" return paths
to the host's include directories (/usr/share/eolian/include).
Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
|
|
|
|
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.
|
|
|
|
|
|
|
|
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
|
|
Currently bindings/eina-cxx/{eina_clone_allocators.hh, eina_list.hh,
eina_array.hh} include Eo.h, so it's actually already a dependency. This
patch just reflects it in eina-cxx.pc.
|
|
Reviewers: cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1439
|
|
|
|
|
