The EFL containers are widgets that contain other widgets. They belong to the following categories:
- named (parts, swallows)
- linear (box)
- grid (table and grid)
The goal of the EFL Containers API is to unify all box, grid and parts code into a single sensible API set.
Edje and Elm Layout have the concept of parts. Those parts represent standard objects and so should behave the same way as any other object.
For this, Edje and Elm Layout BOX and TABLE support has been implemented with fake objects that are real EO instances but not Evas Objects. They only proxy calls to a specific part of a layout.
NOTE: This document was written on 2016/04/26 and may not be valid anymore - updated on 2016/05/09
- Efl.Container (prefix efl_content)
Those objects are proxies retrieved by efl_content_get.
These objects implement the following legacy code:
edje_object_part_box_append(edje, "part", subobj);
Eo *box = efl_content_get(edje, "part");
Since the above usage brings too many lifecycle issues (do you hold a ref? for how long? can the proxy die? etc...) let's refine the usage to be the same as eo_super. (2016/05/09)
efl_pack(efl_content_get(edje, "part"), subobj);
The lifetime of the proxy object is bound to the internal BOX or TABLE object, and it may be deleted.
The proxy object is valid for one and only one function call. (2016/05/09)
We might want to implement the same for TEXT & TEXTBLOCK parts.
A custom layout function can be implemented by creating a layout engine class. The easiest way to do so is to use an Eo file and eolian, but it can also be done inline in C (FIXME: need a simpler solution).
- efl_content_remove and efl_pack_unpack are the same
- pack_remove_all and pack_clear: do these belong to Efl.Container?
- Much work is left to do on Efl.Ui.Grid: proper layout, Elm Grid-like behaviour
- Stack mode is not implemented in Efl.Ui.Box
- Single element containers & default part handling: need a simple content_get / content_set which doesn't take a part name.