E17

From Openmoko

(Difference between revisions)
Jump to: navigation, search
Line 13: Line 13:
 
In fact, i started thinking about this [http://edevelop.org/node/2420 1] [https://lists.gnumonks.org/pipermail/openezx-devel/2006-April/000227.html 2] [http://www.motorolafans.com/MotorolaFansPHPbb/viewtopic.php?t=3585 3] [http://lists.jerryweb.org/pipermail/mkezx/2007-January/000363.html 4] some time ago (2006-04), and some other people might be interested in participating. And some [http://lists.jerryweb.org/pipermail/mkezx/2007-January/000364.html already started], in the mkezx project for instance.
 
In fact, i started thinking about this [http://edevelop.org/node/2420 1] [https://lists.gnumonks.org/pipermail/openezx-devel/2006-April/000227.html 2] [http://www.motorolafans.com/MotorolaFansPHPbb/viewtopic.php?t=3585 3] [http://lists.jerryweb.org/pipermail/mkezx/2007-January/000363.html 4] some time ago (2006-04), and some other people might be interested in participating. And some [http://lists.jerryweb.org/pipermail/mkezx/2007-January/000364.html already started], in the mkezx project for instance.
  
'''Live examples:'''
+
===Live examples===
 
* installing e17 on a Zaurus C-860 (VGA screen); the tutorial is very interesting, we can spare a lot of work (hopefully): http://gefechtsdienst.de/uman/Zaurus_C-860/E17_setup/index.html Here's a [http://gefechtsdienst.de/uman/files/zaurus/e17-apply-config.sh script] for automatic e17 parameters applying.
 
* installing e17 on a Zaurus C-860 (VGA screen); the tutorial is very interesting, we can spare a lot of work (hopefully): http://gefechtsdienst.de/uman/Zaurus_C-860/E17_setup/index.html Here's a [http://gefechtsdienst.de/uman/files/zaurus/e17-apply-config.sh script] for automatic e17 parameters applying.
 
* [http://mail.pdaxrom.org/contrib/daal/ OpenZaurus] has e17 in it's packages.
 
* [http://mail.pdaxrom.org/contrib/daal/ OpenZaurus] has e17 in it's packages.
 
* [http://www.oesf.org/forums/index.php?showtopic=21930&hl=e17 e17 thread in open embedded forums]
 
* [http://www.oesf.org/forums/index.php?showtopic=21930&hl=e17 e17 thread in open embedded forums]
  
'''What's new then?'''
+
===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.
 
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's to do?===
  
 
e_customization_TODO:
 
e_customization_TODO:

Revision as of 16:18, 8 April 2007

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

"Porting" e17

In fact, i started thinking about this 1 2 3 4 some time ago (2006-04), and some other people might be interested in participating. And some already started, in the mkezx project for instance.

Live examples

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'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?

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:

It has already been partially ported on:

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

"Porting" e17

In fact, i started thinking about this 1 2 3 4 some time ago (2006-04), and some other people might be interested in participating. And some already started, in the mkezx project for instance.

Live examples:

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.

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?

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:

It has already been partially ported on:

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