E17

From Openmoko

(Difference between revisions)
Jump to: navigation, search
 
(catchg)
 
(18 intermediate revisions by 7 users not shown)
Line 1: Line 1:
===Using [http://www.enlightenment.org/Libraries/Overview/ EFL]-based apps===
+
=Using [http://www.enlightenment.org/Libraries/Overview/ 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 [http://www.enlightenment.org/Libraries/Overview/ EFL]-based UI?
 
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 [http://www.enlightenment.org/Libraries/Overview/ EFL]-based UI?
Line 9: Line 9:
 
* or develop our own EFL-based UI, such as Rasterman's [http://www.rasterman.com/files/eem.avi EEM] proof of concept
 
* or develop our own EFL-based UI, such as Rasterman's [http://www.rasterman.com/files/eem.avi EEM] proof of concept
  
===="Porting" e17====
+
==Rolling our own EFL-based UI==
  
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.
+
EEM is a proof of concept: a simple UI showing an app launcher/menu on an embedded device.
  
What's to do then?
+
Links:
* tuning the config for the size of the device (compilation options, configuration, small patches about input methods)
+
*[http://www.rasterman.com/files/eem-live.avi Filmed video of the demo running an ipaq]
* benchmarking
+
*[http://www.rasterman.com/files/eem.avi Captured video]
* developing custom modules (ex: GPRS signal)
+
*[http://www.rasterman.com/files/eem.tgz Source code]
  
'''Live examples:'''
+
==Tweaking e17 for openmoko==
* 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://www.oesf.org/forums/index.php?showtopic=21930&hl=e17 e17 thread in open embedded forums]
+
  
'''What's new then?'''
+
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.
 
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:
 
e_customization_TODO:
Line 36: Line 53:
 
* develop a finger wheel module?
 
* develop a finger wheel module?
  
====Rolling our own EFL-based UI====
+
=The EFL libs=
 
+
EEM is a proof of concept: a simple UI showing an app launcher/menu on an embedded device.
+
 
+
Links:
+
*[http://www.rasterman.com/files/eem-live.avi Filmed video of the demo running an ipaq]
+
*[http://www.rasterman.com/files/eem.avi Captured video]
+
*[http://www.rasterman.com/files/eem.tgz Source code]
+
 
+
It has already been partially ported on:
+
*[http://archive.gp2x.de/cgi-bin/cfiles.cgi?0,0,0,0,46,1647 GP2X]
+
*[https://svn.jerryweb.org/public/mkezx/trunk/packages/evas/ mkezx]
+
 
+
====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.
 
''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.
Line 62: Line 66:
 
All descriptions beyond come from http://www.enlightenment.org/Enlightenment/DR17/ .
 
All descriptions beyond come from http://www.enlightenment.org/Enlightenment/DR17/ .
  
=====Evas=====
+
==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 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.
Line 72: Line 76:
 
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.
 
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==
  
 
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.
 
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.
Line 78: Line 82:
 
A Quick list of its features:
 
A Quick list of its features:
  
    * Scalable bitmap images
+
* Scalable bitmap images
    * Highly compressed in-lined images
+
* Highly compressed in-lined images
    * Lossless and lossy compression with or without alpha channel
+
* Lossless and lossy compression with or without alpha channel
    * In-lined compressed truetype fonts
+
* In-lined compressed truetype fonts
    * Multiple inbuilt font effects
+
* Multiple inbuilt font effects
    * Automatic font sizing based on size or area
+
* Automatic font sizing based on size or area
    * Text compression and ellipsis based cutting
+
* Text compression and ellipsis based cutting
    * Rectangle objects
+
* Rectangle objects
    * Configurable color scheme system
+
* Configurable color scheme system
    * Ability to embed Edje objects within Edje objects
+
* Ability to embed Edje objects within Edje objects
    * Embryo scripting language for complex interactions
+
* Embryo scripting language for complex interactions
    * Sand-boxed scripts so they cannot do much damage
+
* Sand-boxed scripts so they cannot do much damage
    * Alpha blending
+
* Alpha blending
    * Completely scalable and re-sizable layout and interface metrics
+
* Completely scalable and re-sizable layout and interface metrics
    * Completely calculated tweened animation for ultra-smooth display
+
* Completely calculated tweened animation for ultra-smooth display
 +
 
 +
[[Edje examples|See edje examples]]
 +
 
 +
[[Category:Middleware]]

Latest revision as of 08:10, 19 July 2009

Contents

[edit] 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

[edit] 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:

[edit] 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.

[edit] 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 :)

[edit] What are the problems?

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

[edit] 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?

[edit] 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/ .

[edit] 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.

[edit] 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

See edje examples

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.

What's to do then?

  • tuning the config for the size of the device (compilation options, configuration, small patches about input methods)
  • benchmarking
  • developing custom modules (ex: GPRS signal)

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