Enlightenment 0.17 : E17
D'après nos sondages en ligne et d'autres répartis à travers le monde, une grande quantité d'utilisateurs ne se servent pas d'environnements tout intégrés. Ils préfèrent faire leur petite cuisine en sélectionnant les bons morceaux là où ils se trouvent. Enlightenment entre dans cette catégorie.

La version actuelle stable d'Enlightenement, la 0.16.5, est largement utilisée. Les détracteurs lui reproche une lenteur et une gourmandise en mémoire. Ceci ne fait que prouver qu'ils n'ont pas utilisé ce gestionnaire de fenêtres depuis longtemps. Rasterman, de son vrai nom Carsten Haitzler, n'a jamais démenti ces choix techniques.

Je me souviens des premières interviews où l'équation a été posée : s'il faut faire un choix entre ressources processeur et ressources mémoire, la solution est de tirer profit au maximum de la puissance de calcul, quitte à perdre en optimisation mémoire. Les CPU coûtent toujours plus cher que la mémoire, ce choix est toujours valide.

La prochaine grande étape se matérialisera par l'arrivée d'Enlightenment 0.17. Ne demandez pas quand cela arrivera, la réponse est claire : quand ce sera prêt. Mais nous pouvons déjà tracer une esquisse de ce que sera le desktop-shell du futur, car E17 ne sera jamais autre chose que cela, doublé d'un gestionnaire de fichiers. Rasterman l'a clairement annoncé dès le début des développements : Enlightenment 0.17 sera un shell graphique. Entendez par là un mélange entre gestionnaire de fenêtres, de fonds d'écran et gestionnaire de fichiers.

La comparaison avec des applications ou des programmes existants est assez difficile puisque nous avons d'un côté les environnement graphiques comme GnuStep, KDE ou GNOME et de l'autre, les gestionnaires de fenêtres. E17 sera quelque chose d'à la fois très différent et en même temps placé juste entre ces deux catégories.

E17 repose sur des bibliothèques solides que Rasterman et son équipe ont écrites ou réécrites :

- Imlib2 est la réécriture de la bibliothèque de fonctions graphiques. Celle-ci est chargée des manipulations de base sur les images et les fichiers images (chargement, affichage, redimension, etc.). Cette bibliothèque est d'ores et déjà stabilisée et seules des modifications mineures y sont apportées. Rasterman considère qu'Imlib2 est un nettoyage d'Imlib et une évolution dans le sens des demande qu'il a reçu.
Ainsi, Imlib2 utilise des pilotes modulaires pour charger les différents formats de fichiers graphiques. Ceci permet d'ajouter dynamiquement des fonctionnalités à Imlib2 et ce, tenez-vous bien, même si Imlib2 est déjà chargée et en cours d'utilisation par une application.

- Evas est la bibliothèque canevas reposant à la fois sur Imlib2, GLX (eh oui !) et X11. Il s'agit d'une couche d'abstraction permettant un rendering d'images, de polices anti-aliasées, de dégradés (avec alpha) et de lignes. Le render peut utiliser plusieurs modes comme celui de X11, le mode soft ou encore le mode accéléré. Evas est ainsi capable d'utiliser les ressources matérielles mises à disposition par le GLX pour afficher tous ces éléments graphiques en RGBA 24bits. Evas est le c ur d'E17.

- Ebits est une couche supplémentaire au-dessus d'Evas. Elle permet la manipulation de blocs de manière beaucoup plus simple pour la gestion des fenêtres du futur Enlightenment.

- Ecore est une bibliothèque chargée d'intercepter les appels X11 classiques et de les traduire en instructions accélérées pour Evas. Ecore est également chargée de gérer les signaux X11 et de les interpréter pour le reste de l'environnement. On peut comparer Ecore à une couche de traduction 100% compatible Xlib qui détournerait les instructions et les événements afin de les gérer via les autres bibliothèques composant le système de base d'E17.

- Edb est également une couche d'abstraction, mais cette fois pour le moteur de bases de données Berkeley. Edb intègre les sources de db 2.7.7 et assure ainsi une compatibilité future. Rasterman a, bien sûr, entièrement optimisé le fonctionnement de ce code afin d'obtenir les meilleures performances possibles.

- Etox est au texte ce que Ebits est aux images : une couche au-dessus d'Evas permettant de faciliter la manipulation de texte sous forme de blocs.

- Efsd est l'interface de gestion des fichiers. Rappelez-vous qu'E17 intégrera un gestionnaire de fichiers. Efsd est non seulement une bibliothèque mais également un démon permettant les manipulations classiques sur les fichiers (copie, déplacement, suppression).

Une grande attention a été portée sur la propreté du code de chacun de ces éléments. Pour Rasterman, Imlib2, tout comme E ou les autres parties de code provenant d'E16, est principalement le résultat d'un nettoyage de code. Entendez par là que l'homogénéité de l'ensemble est extrêmement travaillée et que le prochain E17 tirera partie d'une architecture nouvelle du code.
E17 devra être beaucoup plus rapide que n'importe quelle autre application du même type. C'est d'ailleurs là le but avoué de Rasterman : ne laisser aucune chance à une autre implémentation faisant le même travail. Chaque élément d'E17 devra aller plus vite que son concurrent direct. On pense tout naturellement à la comparaison de gdk-pixbuf avec Imlib2.

Les choix de conception de Rasterman vont à l'encontre de ceux faits par d'autres projets comme KDE ou GNOME. Bien que ne sévissant pas dans la même catégorie, on peut comparer les objectifs poursuivis. Alors que les deux projets que je viens de citer tentent de mettre en uvre des mécanismes objets chapeautant l'ensemble de l'environnement (comme Corba), E17 intégrera directement cet aspect objet dans le code définitif. E17 utilisera le plus vieux système objet existant il a plus de trente ans maintenant et Rasterman le résume assez aisément par les termes fork() & exec().

Eh oui, Unix met à la disposition du développeur des mécanismes systèmes permettant de réaliser, avec un peu d'effort, les mêmes choses qu'avec des implémentations de niveau supérieur. N'oublions pas que la force d'E17 sera sa rapidité, et dans ce cas, implémenter un mécanisme de partage d'objets ne ferait que ralentir le système.

Pour l'heure, un partie du code est stabilisée (comme Imlib2 par exemple), mais le CVS continu d'évoluer rapidement. Il est d'ores et déjà possible de lancer E17, mais celui-ci n'est pas encore véritablement utilisable. Il vous faudra patienter le temps nécessaire avant de vous mettre ce magnifique morceau sous la dent.

Liens
Enlightenment homepage
http://www.enlightenment.org

La page E sur le site de Rasterman
http://www.nl.rasterman.com/pages/e.html

La documentation d'Evas
http://www.nl.rasterman.com/files/evas.pdf
http://www.enlightenment.org/pages/htmlized/evas/

Documentation Imlib2
http://www.enlightenment.org/pages/imlib2.html