Unified EFL Tradeoff
Unified EFL Tradeoff
As the Unified EFL API and underlying libraries and structures develop we took decisions that reflect in the final API. These sometimes result in what looks like a trade-off or can have a negative side effect. These decisions are listed below for future reflection with the possibility of improving should the right solution be found.
| Decision | Impact | Reason |
|---|---|---|
| EFL will embed the full Enlightenment theme | The EFL release and installed size is larger than necessary | Consistency of the desktop look and feel was desired and this decision means that Enlightenment will always have the same default theme as apps built with Elementary / Efl.Ui. Also almost all of the theme for Elementary is common with Enlightenment at least in terms of major data usage (images and icons). Only some gadget imagery would be unique to Enlightenment. Even the default wallpaper should be shared as a kind of "backing object" apps can use. |
| Newly created objects may disappear if parent is destroyed | Within code where you do not control the parent object within your code it is possible that a race condition may result in an invalid parent pointer which could cascade to a race condition where your new object is destroyed before you have finished creating it. If you absolutely cannot depend on parent staying around efl_add_ref() will add with an extra ref that belongs to your scope, but you MUST efl_unref() on exit from the scope. Use with care. | The decision was based on most objects (for example widgets in a UI hierarchy) having a logical parent who's life cycle you want to use. We automatically assign a new object to a child of the parent to avoid having to manually control references saving a line of code per object. It also makes sense for many other kinds of objects such as filesystem shadowing (directories and files in the directory), Network I/O (Server object has child client objects) etc. |
| Objects will always have a parent | If you create an object with a NULL parent or set a NULL parent then this is basically illegal (only a handful of objects that EFL itself creates for you will have NULL parents, but none anyone outside of EFL itself will create). The only objects at this point that should have a NULL parent are loop objects or ector objects which are still internal only. In a case where the parent is NULL then the creator is responsible for the life cycle of the object entirely. | When you have a parent you have a clearly defined ownership model over life cycle and you get automatic cleanup of children on deletion of parent, but it also cleanly allows tracking of which loop drives this object so any async callbacks can be sensibly handled. |
- Last Author
- raster
- Last Edited
- Jan 25 2018, 9:14 PM
- Projects
- None
- Subscribers
- None