Page MenuHomePhabricator

Workflow of an Application Developer using Edje
Updated 2,097 Days AgoPublic

Introduction

Edje is an library that provides flexible abstraction layer between code and interface. In this wiki you can find lots of code examples, you can also check EDC reference to know the proper syntax and properties available for the description file. But what's the best way to organize your work with it and be more productive?

Use Case Scenarios

NOTE: TODO: add image with two groups of professionals (can/should be stereotyped)

The canonical scenario is composed of the following roles:

  • Designer and User Experience: professionals that are usually experienced in human behavior and trends. Often they are artists with formal arts education or related, like Marketing and Publicity, Photography, Printing and Publishing. They often have distinct roles:
    • Graphics Designer: draws nice images, specifies colors, sizes and are able to produce static files (JPEG, PNG...). They often work with tools such as PhotoShop, Illustrator, The Gimp, Inkscape, Blender, Corel Draw, 3D Studio, etc. They deliver static content.
    • Graphical User Interface Workflow Designer: provides work flows on how things should react to user interaction, animations and visual effects. They often work with tools such as Flash, PowerPoint or any movie/animation editing application. They deliver animated content, often based on Graphics Designer output.
  • Computer Scientist or Engineer: professionals that have technical background, knows how memory and CPU work together, APIs and everything. They often have distinct roles:
    • Back-end Developer: provides core functionality of application, like data base or network access, calculations that are specific to the problem. They deliver software libraries
    • Front-end Developers: responsible by putting together the work of the Designer and User Experience and Back-end Developers, they will get data from user, validate, feed the back-end, then get the results and present to user using the required guidelines, doing all the nice effects required.

Of course some of these roles can be played by the same persona. It is recommended that the Computer Scientist don't play the Designer and User Experience, and vice versa, otherwise you'll likely have a software that is ugly and unusable or something that does not work as the logic is missing. Unfortunately it is common to find a single person playing all these roles as resources are scarce, especially in Free Software world.

Deliverables and Agreements

Independent on how many people are involved, these roles should be well defined to avoid problems in future and at some point, there must be an specification on what to do and how to do. This required well defined deliveries to avoid problems and make it easy on the long run.

NOTE: TODO: add basic worflow of two groups or professionals delivering, then agreeing (hand shaking) and then working more on it (loop).

Basic deliveries recommended:

  • Designer and User Experience:
    • Graphics Designer: flat (no layers!) images as PNG and JPEG, properly named and sized. In more details:
      • naming scheme: agree and follow a name scheme with your developer, you might want to add name spacing to make things clear to both, like moduleXYZ_button_icon_close.png
      • sizing: if two or more images should represent different states of the same thing, then it's often easier to make them the same size. For example button_bg_standard.png, button_bg_hover.png and button_bg_clicked.png all should be the same size (also, not naming!)
      • PNG or JPEG? often PNG contains alpha (transparency) layer and is slower, the files are also compressed without loss, so they're bigger and slower to read, but are full-resolution/quality and good for icons and buttons. JPEG is often smaller, opaque and compressed with loss, thus they will slightly loose details but are faster to handle, then are good choices for backgrounds and large images.
      • specifying border, tiling and others Edje is provides handy functions to layout images in a tiled fashion, as well as automatically resize borders and create frames (just border, without painting middle). But developer needs to know sizes and coordinates to do so, one way is to provide it written as text or provide an annotated image to be used as guide.
    • Graphical User Interface Workflow Designer: one effect at once, easy to follow, with notes. Similarly to Graphics Designer, pay attention to naming and sizing! Do mockups and evaluate them with users before requesting developers to implement them, as they will likely take orders of magnitude more to have it working in fast and extensible code than one designer to do it as a fixed case in Flash. Position of elements should be annotated on the files themselves or written in a document (that can be the EDC file itself, in this case define the signals and part naming).
  • Computer Scientist or Engineer:
    • Back-end Developer: often do not deal with designers, but their indirect requests through front-end developers may be to change the design to provide asynchronous/non-blocking APIs or different values to be better presented. Delivers libraries, header files and basic API usage documentation.
    • Front-end Developers: interacts with designers and creates the EDC files based on the specifications of the workflow designer or use files provided by them. If receiving the EDC, must know the signals and part names, otherwise should specify them.
      • naming scheme: take it seriously and avoid useless work and communication between you and designer. Follow the signals and parts naming to interface with code. Example, code-accessible parts should start with gui, be followed by type and then the unique identifier, such as "gui.text.temperature". Signals should follow similar convention, be clear if there should be a source for actions or not: "gui,temperature,show" (without source) or "gui,show" "temperature".
      • don't change assets: as developers hate being told how to do their logic, designers often hate having their images and animations changed without previously acknowledgment. Before doing any change, talk to designer and request approval (this is listed here since it is the most common source of trouble)

Assuming most of time you get back-end and graphics from someone else, often the application developer that uses Edje keeps doing the Front-end Developer role. So the rest of this document focus on it. If you are lucky enough to have designers to do EDC for you, then they might be interested in it as well.

Specification Template

The following specification template is used with success by front-end developers and their peers:

Public Parts

PartTypeRequiredDescription
gui.text.temperatureTEXTyesshows current temperature formatted as text
gui.drag.vbarfreenoif existent, will be set from 0.0-1.0 to vertical bar positioning
gui.wid.button.dismissEXTERNAL:elm_buttonyesdismiss the current dialog

Public Signals

SignalSourceRequiredAction
gui,clicked,unit_changeemptynorequest application to change unity of temperature
gui,clicked,nextemptyyesrequest application to change to next city
gui,animnextyesstart animating the change to the next city, after starts "gui,anim,end" "next" is emitted!
gui,anim,endnextyesnotify end of action started by "gui,anim" "next"
NOTE: these examples mixes naming scheme and is not good for consistency. It was used to illustrate various possibilities.

Messages

IdTypeRequiredDescription
1MSG_FLOATyesinforms the current temperature as float point in the current unit
2MSG_STRING_INTyesinforms the current unit code (int) and name (string)

Part Position and States

Often this is done with a Flash or annotated picture, you choose it. Designers should annotate the image with overlay graphics with dimensions.

NOTE: TODO: example flash and annotated picture.

Part Colors

Specify colors as usual Red-Green-Blue-Alpha values from 0-255. They can be listed in a simple table as follows:

PartRedGreenBlueAlpha
bg000255
text255255255255

Note that in some systems, specially embedded, you will have 16 bits per pixel of color depth. This means you have less color resolution and combinations and results might be not what you expect, specially if using the 16bpp Evas engine (using 32bpp/regular engine will likely produce less artifacts as it will do dithering, but that will be slower and your hardware might not be able to cope with it). To play well with it, take some time to understand RGB565ColorSpace.

Imported from https://trac.enlightenment.org/e/wiki/ApplicationDevelopmentWithEdjeWorkflow
History:
1 barbieri 2009-12-21 19:12:42 Initial version, needs reviewing and lots of TODO left.
2 barbieri 2009-12-21 19:27:00
3 barbieri 2009-12-21 20:01:39 typo

Last Author
beber
Last Edited
Aug 22 2013, 3:54 PM
Projects
None
Subscribers
None