From 7f0b7555195402fd0d0dcbae1a9db49035ad5b1c Mon Sep 17 00:00:00 2001 From: Nate Drake Date: Thu, 16 Nov 2017 10:09:02 -0800 Subject: [PATCH] Wiki page about-efl-draft.md changed with summary [] by Nate Drake --- pages/playgroud/about-efl-draft.md.txt | 24 +++--------------------- 1 file changed, 3 insertions(+), 21 deletions(-) diff --git a/pages/playgroud/about-efl-draft.md.txt b/pages/playgroud/about-efl-draft.md.txt index b4642aa6f..dd9f14bb6 100644 --- a/pages/playgroud/about-efl-draft.md.txt +++ b/pages/playgroud/about-efl-draft.md.txt @@ -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 |