Page MenuHomePhabricator

MVC List
Updated 2,971 Days AgoPublic

EFL could provide a Model-View-Controller (MVC) list in order to have high-performance lists for huge amount of data. This is possible because MVC decouple data (Model) from what is required to display it (View), so we don't need to have one Evas_Object per existing list row.

In order to provide this Model-View-Controller, we need to specify a API to allow these parts to be developed. The suggested API is:

typedef void (*MVC_Value_Set)(Evas_Object *list,
                              Evas_Object *row_renderer,
                              void *row_data, /* row contents */
                              void *data);
typedef Evas_Object *(*MVC_View_Add)(Evas *evas,
                                     void *data);

typedef void (*Data_Free)(void *data);

typedef struct MVC_Model_Funcs {
    int (*length)(void *model),
    void *(*value_get)(void *model, int index),
    void *(*slice_get)(void *model, int *start, int *end)
    /* TODO: will slice be an array, list or an iterator or ...? */     
} MVC_Model_Funcs;

void mvc_list_callback_value_set_set(Evas_Object *list,
                                     MVC_Value_Set *value_set,
                                     void *data,
                                     Data_Free data_free);

void mvc_list_callback_view_add_set(Evas_Object *list,
                                    MVC_View_Add *renderer_add,
                                    void *data,
                                    Data_Free data_free);

void mvc_list_model_set(Evas_Object *list,
                        void *model,
                        Data_Free model_free,
                        MVC_Model_Funcs *funcs,
                        Data_Free funcs_free);

Usage example:

void value_set(Evas_Object *list
               Evas_Object *row_renderer,
               void *row_data,
               void *data)
    edje_object_part_text_set(row_renderer, "text", row_data);

Evas_Object *renderer_add(Evas *evas,
                          void *data)
    Evas_Object *o;
    struct edje_spec *spec = data;

    o = edje_object_add(evas);
    edje_object_file_set(o, spec->file, spec->group);

    return o;

void spec_free(void *data)
   struct edje_spec *spec = data;

struct edje_spec *spec;
spec = malloc(sizeof(*spec));
spec->file = strdup("file.edj");
spec->group = strdup("group");

Model *model;
model = model_new();

Evas_Object *view;
view = my_mvc_list_add(evas); /* some mvc implementation */
mvc_list_callback_value_set_set(view, value_set, NULL, NULL);
mvc_list_callback_view_add_set(view, renderer_add, spec, spec_free);
mvc_list_model_set(view, model, model_free, model_funcs, NULL);

model_append(model, "some value");

Extra ideas:

  • Provide easier way (helpers) to work with Edje as row renderers;
  • Provide standard Evas_List-like (or based) models;
  • Provide a row for standard models that do introspection somehow, enable automatic mapping to Edje object parts. Example
  • Enable Embryo to issue edje_object_part_*_set() so we can use Embryo to write value_set() and also add new models.

Overhead Files For Edje Theme Correctness

For those of you who loved GTK-QT-Edje engine. Prepare your bandwidth for another of my awesome ideas. As always, feel free to contribute, this is a wiki! you don't have to ask for permission AND in the worst case, we can always revert some changes here and there. Dresb 05:05, 18 April 2008 (PDT)


This article describes a method to control the structure of groups, parts and programs of Edje object for compliance with a given application's requirements.


I have seen the question "are you using the default theme?" Enough times to realize there are consistency issues with Edje's free(dom) approach to interface development. True, E17 is under heavy development and of course its requirements are going to change often. But its specially large applications like E17 this approach will benefit the most, even in a stable state.

Creating new themes is hard. If we take a look at theme list we will see that most themes are rehashed versions of themes created by developers. Theme debugging is also hard. Even when programming a simple application like the plain-edje-viewer I came across interface problems I wasn't sure to blame my usage of Evas API, Edje API or theme creation, problems jumped from one to the other.

Standardization of a method to specify what we intend to do with a given interface can make theme creation easier because:

  • An updated, compliant "skeleton" theme could be automatically generated in each new version.
  • The designer will be able to check its theme for problems as he develops each group. He will also know what elements are left to implement and what do they entail.

The application developer must decide which specifications will be mandatory (trigger an error) or optional (trigger a warning). A nice approach would be allowing the designer to specify when he is intentionally ignoring the spec, and only print a warning in that case.

Possible Approaches

  1. We could create an application that parsed the C code of a given EFL based application to automatically generate an specification file by analyzing calls like edje_object_part_swallow, edje_object_part_text_set, edje_object_signal_callback_add or edje_object_signal_emit. These specifications would be rather simplistic and look like "group X must have part Y of type SWALLOW" or "group X must handle signal Y".
  2. A EDC like language for theme specification could be created and use a function like edje_object__check(ptr_object,"role_name",ptr_spec). The spec file would look like this:
role {
  name: "play_button"; // This name does not have to be the name of the group
                       // or anything at all. It's for internal use.
  parts {
    part: "name",  type, "description";
    part: "label", TEXT, "Needed to set the label of the button";

  signals {
    emitted {
       signal: "emission", "source", "description";
    expected {
       signal: "PLAY", "*", "Will begin playing the currently selected song."; 

role {
   name: "volume_bar_thingie";

Using an EDC like syntax would probably make it easier to implement the parser and compiler. We can always add a mechanism to output the result in a more readable way.

How this would be used

This could be used by a stand alone application for the designer, as a function for the developer to use in his application and determine when to fail or simply warn. Or both.

Imported from
1 mcalamelli 2009-01-30 01:22:09

Last Author
Last Edited
Sep 5 2013, 2:18 PM