E17

From Openmoko

Revision as of 10:32, 1 October 2007 by Raster (Talk | contribs)

Jump to: navigation, search

Contents

Using EFL-based apps

As an e17 user for quite some time, i always was astonished by the level of efficiency, elegance and eye-candy without using any fancy compositing X features: e17 will work on any Xserver. It seems that using GTK+ for the base UI is a problem: slow, sluggish... So, why not using an EFL-based UI?

These libs are quite embedded-oriented, and could be a great match for openmoko. Some people already worked on the subject, having mitigated results, but these libs definetly work on handeld devices.

There are 2 ways to go:

  • either port/tune e17 so that it fits into a VGA (640*480) screen, and optimized for finger operation as well as touchscreen
  • or develop our own EFL-based UI, such as Rasterman's EEM proof of concept

Rolling our own EFL-based UI

EEM is a proof of concept: a simple UI showing an app launcher/menu on an embedded device.

Links:

Tweaking e17 for openmoko

In fact, we mostly want to use some of the features like:

  • the shelves
  • the modules

e-wm is overkill and underoptimized for openmoko. Drawing an evas surface in a gtk window may do the job better

(Edit from Raster) - I'll dispute that. E-wm isn't optimised for layout of windows as a "1 window at a time" such as matchbox, but very little is stopping that. You are not going to get better with a GTK created window then hooking in EFL. It's going to be more overhead. E-wm can do all of it and it just need tweaking and fixing. In fact I have already started that work - I've modularised a lot of the WM so it has most elements as replacable items. It does not need much work to be optimised for openmoko. Then you get shelves, modules, a file manager, window manager and more for "free". Yes it needs to be more phone aware, and that is just a matter of modules.

What's new then?

Ok, nothing's new under the sun, but we may push the customization further, so that e17 on our marvelous 640*480 screen (quite small...) is usable AND nice.

Because:

  • the screen is small !
  • we need finger operation
  • there's a phone in the neo :)

What are the problems?

  • e-wm needs a keyboard, mouse
  • neo's screen is 300 dpi

What's to do?

e_customization_TODO:

  • scaling tuning: proportions, size of the elements
  • dedicated virtual desktop for the menu
  • how to force 1 app = 1 virtual desktop, with automatic vdesktop addition

Modules_TODO:

  • develop GPRS signal module (may be based on temperature module), adapt the reusable ones: battery, tclock/clock, pager
  • develop a finger wheel module?

The EFL libs

In developing DR17 it was made clear that we needed an entirely new set of libraries and tools. Raster had a bold vision of what was possible and where he wanted the next release to go, starting with Imlib2 and EVAS, and eventually growing into new libraries largely based on or around EVAS. It became clear that the usefulness of these libraries and tools went far beyond the DR17 release itself, just as Imlib did in DR16. Thus the collective library back-end of DR17 was given the independent title: the Enlightenment Foundation Libraries, or EFL for short.

The EFL contains solutions for almost any graphical interface task, far beyond just rendering images. EVAS provides a highly optimized canvas library. Ecore provides a simple and modular abstraction interface and advanced event management including timers. Etox provides a complex text layout library complete with theme-able text stylization capabilities (previously Estyle). EDB provides a compact database format for intuitive and easy configuration management, including the storing of binaries. EET provides an integrated and flexible container that ends the traditions of providing themes in tarballs. Edje provides a revolutionary library and tool set for completely abstracting application interfaces from their code, including a complex and flexible method of designing interfaces. EWL provides a complete widget library built on all the other components of the EFL. And more!

From: http://www.enlightenment.org/


http://www.rasterman.com/files/efl.png

All descriptions beyond come from http://www.enlightenment.org/Enlightenment/DR17/ .

Evas

Evas is a very core part of the EFL. It is the rendering and display management engine that sits under anything you see on a screen. It does all the work of managing display objects, their state, state changes, layering, rendering and scaling, image loading, text rendering, update handling, optimizing the display pipeline to avoid work and more. It does a lot of the grunt work of display, and is portable beyond X. It even runs in the framebuffer directly without needing X, under Trolltech's Qtopia, on DirectFB, can render into a memory buffer, and use OpenGL to accelerate rendering. It is extremely flexible and very powerful, saving a lot of time writing repetitive drawing routines that often end up not performing optimally as to do so takes a lot of time, care and effort that most programmers would not want to spend, because it distracts from the important work of making their application.

Evas on embedded

But despite all of the things that Evas can do, it is not very large. It has been kept small and lean to make it viable for use on NOT just heavy-weight desktops, but also on limited resource devices such as PDA's, mobile phones and Smart phones, Stereo systems, DVD Players, PVR/DVR Systems and more. It has already been ported to Mobile phones and PDA's, PVR/DVR systems and has proved itself capable of driving these displays very nicely with beautiful effects. The developer does not have to change how they code for a device or their desktop as the API and rendering are the same, so no special development environments or emulators are needed. This saves time and effort, allowing desktop and device code to be shared and maintained easily. Also since Evas hides the details of the devices display format, and virtualizes the display at an object level, the programmer doesn't need to care how to render things. They can use a standard system that is universal across all instances of Evas.

Evas provides alpha blending, high quality scaling of images, anti-aliased truetype text, gradients, lines, polygons and more. The list of supported objects is growing, and can be extended via smart objects. It has an interface mechanism to allow for video data to be efficiently handled (which is what Emotion exploits) and more.

Edje

Edje is one of the more unique parts of EFL, combining many things that Shockwave / FLASH can do with some things it can't, but instead of being designed as a player, it is designed as a slave library to be used by an application to enhance the applications content and display via external compressed data files. It is being expanded continuously, and thanks to its clean design is easy to improve. This is the theme engine behind Enlightenment 0.17 and beyond and at last formalizes Enlightenment themes in a simple and consistent manner.

A Quick list of its features:

  • Scalable bitmap images
  • Highly compressed in-lined images
  • Lossless and lossy compression with or without alpha channel
  • In-lined compressed truetype fonts
  • Multiple inbuilt font effects
  • Automatic font sizing based on size or area
  • Text compression and ellipsis based cutting
  • Rectangle objects
  • Configurable color scheme system
  • Ability to embed Edje objects within Edje objects
  • Embryo scripting language for complex interactions
  • Sand-boxed scripts so they cannot do much damage
  • Alpha blending
  • Completely scalable and re-sizable layout and interface metrics
  • Completely calculated tweened animation for ultra-smooth display
Personal tools

Using EFL-based apps

As an e17 user for quite some time, i always was astonished by the level of efficiency, elegance and eye-candy without using any fancy compositing X features: e17 will work on any Xserver. It seems that using GTK+ for the base UI is a problem: slow, sluggish... So, why not using an EFL-based UI?

These libs are quite embedded-oriented, and could be a great match for openmoko. Some people already worked on the subject, having mitigated results, but these libs definetly work on handeld devices.

There are 2 ways to go:

  • either port/tune e17 so that it fits into a VGA (640*480) screen, and optimized for finger operation as well as touchscreen
  • or develop our own EFL-based UI, such as Rasterman's EEM proof of concept

Rolling our own EFL-based UI

EEM is a proof of concept: a simple UI showing an app launcher/menu on an embedded device.

Links:

Tweaking e17 for openmoko

In fact, we mostly want to use some of the features like:

  • the shelves
  • the modules

e-wm is overkill and underoptimized for openmoko. Drawing an evas surface in a gtk window may do the job better

(Edit from Raster) - I'll dispute that. E-wm isn't optimised for layout of windows as a "1 window at a time" such as matchbox, but very little is stopping that. You are not going to get better with a GTK created window then hooking in EFL. It's going to be more overhead. E-wm can do all of it and it just need tweaking and fixing. In fact I have already started that work - I've modularised a lot of the WM so it has most elements as replacable items. It does not need much work to be optimised for openmoko. Then you get shelves, modules, a file manager, window manager and more for "free". Yes it needs to be more phone aware, and that is just a matter of modules.

What's new then?

Ok, nothing's new under the sun, but we may push the customization further, so that e17 on our marvelous 640*480 screen (quite small...) is usable AND nice.

Because:

  • the screen is small !
  • we need finger operation
  • there's a phone in the neo :)

What are the problems?

  • e-wm needs a keyboard, mouse
  • neo's screen is 300 dpi

What's to do?

e_customization_TODO:

  • scaling tuning: proportions, size of the elements
  • dedicated virtual desktop for the menu
  • how to force 1 app = 1 virtual desktop, with automatic vdesktop addition

Modules_TODO:

  • develop GPRS signal module (may be based on temperature module), adapt the reusable ones: battery, tclock/clock, pager
  • develop a finger wheel module?

The EFL libs

In developing DR17 it was made clear that we needed an entirely new set of libraries and tools. Raster had a bold vision of what was possible and where he wanted the next release to go, starting with Imlib2 and EVAS, and eventually growing into new libraries largely based on or around EVAS. It became clear that the usefulness of these libraries and tools went far beyond the DR17 release itself, just as Imlib did in DR16. Thus the collective library back-end of DR17 was given the independent title: the Enlightenment Foundation Libraries, or EFL for short.

The EFL contains solutions for almost any graphical interface task, far beyond just rendering images. EVAS provides a highly optimized canvas library. Ecore provides a simple and modular abstraction interface and advanced event management including timers. Etox provides a complex text layout library complete with theme-able text stylization capabilities (previously Estyle). EDB provides a compact database format for intuitive and easy configuration management, including the storing of binaries. EET provides an integrated and flexible container that ends the traditions of providing themes in tarballs. Edje provides a revolutionary library and tool set for completely abstracting application interfaces from their code, including a complex and flexible method of designing interfaces. EWL provides a complete widget library built on all the other components of the EFL. And more!

From: http://www.enlightenment.org/


http://www.rasterman.com/files/efl.png

All descriptions beyond come from http://www.enlightenment.org/Enlightenment/DR17/ .

Evas

Evas is a very core part of the EFL. It is the rendering and display management engine that sits under anything you see on a screen. It does all the work of managing display objects, their state, state changes, layering, rendering and scaling, image loading, text rendering, update handling, optimizing the display pipeline to avoid work and more. It does a lot of the grunt work of display, and is portable beyond X. It even runs in the framebuffer directly without needing X, under Trolltech's Qtopia, on DirectFB, can render into a memory buffer, and use OpenGL to accelerate rendering. It is extremely flexible and very powerful, saving a lot of time writing repetitive drawing routines that often end up not performing optimally as to do so takes a lot of time, care and effort that most programmers would not want to spend, because it distracts from the important work of making their application.

Evas on embedded

But despite all of the things that Evas can do, it is not very large. It has been kept small and lean to make it viable for use on NOT just heavy-weight desktops, but also on limited resource devices such as PDA's, mobile phones and Smart phones, Stereo systems, DVD Players, PVR/DVR Systems and more. It has already been ported to Mobile phones and PDA's, PVR/DVR systems and has proved itself capable of driving these displays very nicely with beautiful effects. The developer does not have to change how they code for a device or their desktop as the API and rendering are the same, so no special development environments or emulators are needed. This saves time and effort, allowing desktop and device code to be shared and maintained easily. Also since Evas hides the details of the devices display format, and virtualizes the display at an object level, the programmer doesn't need to care how to render things. They can use a standard system that is universal across all instances of Evas.

Evas provides alpha blending, high quality scaling of images, anti-aliased truetype text, gradients, lines, polygons and more. The list of supported objects is growing, and can be extended via smart objects. It has an interface mechanism to allow for video data to be efficiently handled (which is what Emotion exploits) and more.

Edje

Edje is one of the more unique parts of EFL, combining many things that Shockwave / FLASH can do with some things it can't, but instead of being designed as a player, it is designed as a slave library to be used by an application to enhance the applications content and display via external compressed data files. It is being expanded continuously, and thanks to its clean design is easy to improve. This is the theme engine behind Enlightenment 0.17 and beyond and at last formalizes Enlightenment themes in a simple and consistent manner.

A Quick list of its features:

  • Scalable bitmap images
  • Highly compressed in-lined images
  • Lossless and lossy compression with or without alpha channel
  • In-lined compressed truetype fonts
  • Multiple inbuilt font effects
  • Automatic font sizing based on size or area
  • Text compression and ellipsis based cutting
  • Rectangle objects
  • Configurable color scheme system
  • Ability to embed Edje objects within Edje objects
  • Embryo scripting language for complex interactions
  • Sand-boxed scripts so they cannot do much damage
  • Alpha blending
  • Completely scalable and re-sizable layout and interface metrics
  • Completely calculated tweened animation for ultra-smooth display