Chapter 2. The EFL structure

Table of Contents

Organization of the Libraries
Brief description of each EFL library

While most EFL libraries are under constant development, some of them are clearly more mature than others. Several libraries are considered stable, but that should not mean that they haven't got rough edges. Some libraries have even been declared obsolete (!!!) before the 1.0 release of the EFL. Others are constantly changing so it is hard to either use them in an application or even to understand their scope.

Since this is a concepts document, we will focus only on the foundation libraries that have existed long enough to be useful. If you really get interested in EFL development, joining the developer mailing lists will keep you informed on all the latest ideas and code that at any given moment is central to EFL core developers.

Organization of the Libraries

Several solutions which come in multiple libraries are often advertised in the familiar box stack picture. Low-level libraries are shown at the bottom, while high-level libraries sit on top of them. This implies that the higher levels strictly depend on the low level ones. It also implies that most programmers would always program on higher levels and never actually deal with the infrastructure. This approach may be useful for marketing purposes, but sometimes it confuses developers rather than help them understand. See figure below.

Figure 2.1. The EFL Stack viewed by the Marketing Department.

The EFL Stack viewed by the Marketing Department.

This in not true with EFL. There is one core library which can certainly used by itself, the Evas canvas, and most other EFL libraries add significant value to Evas (Edje, Embryo, Epsilon, etc.). At the same time, low-level libraries can be used by themselves even in non-GUI programs (Ecore, Eet). Thus, to better visualize the EFL, we choose a network structure with Evas and Edje in the center and everything else around. The next picture shows this.

Figure 2.2. The EFL Stack viewed in the programmer way.

The EFL Stack viewed in the programmer way.

This makes clear that the libraries do not form a hierarchy tree that makes every level dependent on the lowest levels. You are not supposed to understand any dependencies from the lines drawn among the libraries. The only thing this denotes is that several libraries can be used by themselves. Application 1 even represents a non-GUI program. You can program console application using only the EFL infrastructure.

From the size of each module you can also understand the importance of a library and whether it is central to the EFL or not. The Evas canvas is clearly the heart of EFL, while the Edje layout engine is the infrastructure that empowers the graphical abilities of Evas. This will also give you an idea on the order that we discuss each library in the next chapters of this document.