Page MenuHomePhabricator

Overhead Files For Edje Theme Correctness
Updated 2,363 Days AgoPublic

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:26:19

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