tangcl
/
www-content
forked from enlightenment/www-content
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Wiki page about-efl-draft.md changed with summary [] by Nate Drake

This commit is contained in:
Nate Drake 2017-11-16 10:09:02 -08:00 committed by apache
parent 479508c17f
commit 7f0b755519
1 changed files with 3 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
pages/playgroud/about-efl-draft.md.txt
View File

@ -9,29 +9,11 @@ Code quality - [EFL Coverity scan status](https://scan.coverity.com/projects/552
![EFL Core](/_media/efl-core.png)
EFL is made up of quite a few libraries that build on top of each other
in layers, steadily becoming higher-level, yet allowing access to
each level as they go. The higher up you go, the less you have to do
yourself. Elementary is about as high up as you get, while you still
access layers below it for day to day things as there is no need for
it to wrap things that work perfectly well as-is.
EFL is made up of quite a few libraries that build on top of each other in layers, steadily becoming higher-level, yet allowing access to each level as they go. The higher up you go, the less you have to do yourself. Elementary is about as high up as you get, while you still access layers below it for day to day things as there is no need for it to wrap things that work perfectly well as-is.
All of EFL exposes its APIs by default in C, with several bindings
available. We are now also working on supporting bindings for various
language as first-class-citizens in EFL by auto-generating the
bindings directly from our new object orientation infrastructure for
C. We stick to C mostly because the libraries have been around for a
long time, were originally written in C and the developers who write
the libraries prefer C. We add OO features in C with tools and
infrastructure where needed. Also moving from C would limit the
audience. C programmers won't be able to access a %%C++%% API (whereas a
%%C++%% programmer can access both C and %%C++%%). That is partly why we aim
to auto-generate bindings so programmers of various languages can get
native-like APIs for their chose language from the same core EFL API
set.
All of EFL exposes its APIs by default in C, with several bindings available. We are now also working on supporting bindings for various language as first-class-citizens in EFL by auto-generating the bindings directly from our new object orientation infrastructure for C. We stick to C mostly because the libraries have been around for a long time, were originally written in C and the developers who write the libraries prefer C. We add OO features in C with tools and infrastructure where needed. Also moving from C would limit the audience. C programmers won't be able to access a %%C++%% API (whereas a %%C++%% programmer can access both C and %%C++%%). That is partly why we aim to auto-generate bindings so programmers of various languages can get native-like APIs for their chose language from the same core EFL API set.
Our components are divided into named libraries or projects. Core EFL
components are:
Our components are divided into named libraries or projects. Core EFL components are:
^Component ^ Description ^
|Evas |Core scene graph and rendering |