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.

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.

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.