Page MenuHomePhabricator

Efl Container Apis
Updated 1,107 Days AgoPublic

Efl Containers API

Purpose

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.

Content and fake objects

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.

Classes

NOTE: This document was written on 2016/04/26 and may not be valid anymore - updated on 2016/05/09

Interfaces

  • Efl.Container (prefix efl_content)
  • Efl.Pack
  • Efl.Pack_Linear
  • Efl.Pack_Grid

See also https://devs.enlightenment.org/~jpeg/efldoc/interfaces/index.html

Widgets

Fake objects

Those objects are proxies retrieved by efl_content_get.

  • Efl.Canvas.Layout_Internal_Box
  • Efl.Canvas.Layout_Internal_Table
  • Efl.Ui.Layout_Internal_Box
  • Efl.Ui.Layout_Internal_Table

These objects implement the following legacy code:

edje_object_part_box_append(edje, "part", subobj);

like:
Eo *box = efl_content_get(edje, "part");
efl_pack_end(box, subobj);
eo_del(box);

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)

Like this:

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.

Functions

  • efl_content_count
  • efl_content_get
  • efl_content_iterate
  • efl_content_part_name_get
  • efl_content_remove
  • efl_content_set
  • efl_content_unset
  • efl_pack
  • efl_pack_after
  • efl_pack_align_get
  • efl_pack_align_set
  • efl_pack_at
  • efl_pack_before
  • efl_pack_begin
  • efl_pack_clear
  • efl_pack_content_get
  • efl_pack_direction_get
  • efl_pack_direction_set
  • efl_pack_end
  • efl_pack_grid
  • efl_pack_grid_columns_get
  • efl_pack_grid_columns_set
  • efl_pack_grid_content_get
  • efl_pack_grid_contents_get
  • efl_pack_grid_directions_get
  • efl_pack_grid_directions_set
  • efl_pack_grid_position_get
  • efl_pack_grid_rows_get
  • efl_pack_grid_rows_set
  • efl_pack_grid_size_get
  • efl_pack_grid_size_set
  • efl_pack_index_get
  • efl_pack_layout_do
  • efl_pack_layout_engine_get
  • efl_pack_layout_engine_set
  • efl_pack_layout_request
  • efl_pack_layout_update
  • efl_pack_padding_get
  • efl_pack_padding_set
  • efl_pack_unpack
  • efl_pack_unpack_all
  • efl_pack_unpack_at

Custom layout functions

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).

See Efl.Ui.Box_Flow

API problems

  • efl_content_remove and efl_pack_unpack are the same
  • pack_remove_all and pack_clear: do these belong to Efl.Container?

TODO

  • 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.
Last Author
jpeg
Last Edited
May 8 2016, 11:25 PM
Projects
None
Subscribers
jpeg