Rasterman a annoncé le 26 avril dernier la sortie des Enlightenment Foundation Libraries (EFL) en version 1.2.0.
#include <vaporware.h>
Alors normalement dans une dépêche Enlightenment, c'est à ce moment qu'on écrit que Enlightenment DR17, E17 pour les intimes, est vraiment révolutionnaire et devrait sortir bientôt, ce qui a le bon goût de déclencher l'hilarité bon enfant d'une grande partie de l'auditoire.
Il faut dire qu'il est plutôt ingrat d'écrire une actu sur E17, car c'est vraiment l'arlésienne du gestionnaire de fenêtres libre. Pensez donc, le dépôt subversion est actif depuis 1999 (NdM : le logiciel subversion datant de 2000, ça devait être initialement du CVS) ! Heureusement, les développeurs ont le sens de l'humour et n'hésitent pas à se moquer d'eux-même. Ce qui n'empêche pas le travail d'avancer, le dépôt en est à la révision 70536 quand j'écris ces lignes. Des entreprises comme Samsung et Profusion travaillent activement dessus.
#define EFL
Et alors, ces EFL 1.2.0, ça change quoi au juste ?
Sur la feuille de route du projet, c'est la dernière étape avant la sortie stable officielle de E17. Même si le projet n'a toujours pas publié le gestionnaire de fenêtre, de nombreuses bibliothèques ont été stabilisées ces derniers mois. Petit rappel des sorties principales (1.0.0) :
- 2008 avril : eet
- 2011 janvier : eina, evas, ecore, embryo, edje, e_dbus, efreet et eeze
- 2012 avril : eio, emotion, ethumb et elementary
La plupart des EFL sont décrites dans cet article, je vous y renvoie pour plus d'information.
Voyons ce qu'apportent les petites dernières :
- eio est une bibliothèque pour gérer les entrées-sorties de manière asynchrone. Elle est utilisée par…
- emotion pour lire les fichiers audio et vidéo via GStreamer, xine ou VLC.
- ethumb sert à créer des miniatures, fonctionne en client/serveur.
- elementary, c'est le gros morceau, le widget toolkit basé sur les autres EFL. Voir la liste des widgets
Ce qui a maintenant été établi par Rasterman, c'est qu'il n'y aura pas d'autre sortie d'EFL avant E17. Il n'est donc pas impossible de voir E17 sortir dans quelques mois.
En attendant, vous pouvez déjà vous amuser avec les EFL ou un snapshot de E17 qui se porte très bien malgré son éternel statut alpha.
SlackE17 r70534
À cette occasion, j'ai donc publié une nouvelle de version de SlackE17, la distribution de package E17 pour Linux Slackware. Chaque archive (i486 et x86_64) contient 29 packages, incluant les dernières EFL, E17 et quelques autres applications. Voir la liste complète ici. Et même si je suis un vil slackeux, je ne peux m’empêcher de parler de Bodhi Linux, une distribution Linux complète basée sur E17.
ePeriodique 0.3
Enfin, pour finir, j'ai également publié ePeriodique 0.3, un tableau périodique basé sur les EFL. Il utilise Elementary (1.0.0) et Edje. Vous pouvez le voir en action avec cette magnifique vidéo WebM/html5 ou sur youtube si c'est slashdoté.
Aller plus loin
- Enlightenment (573 clics)
- Enlightenment (759 clics)
- SlackE17 (169 clics)
- ePeriodique (111 clics)
# Date
Posté par Jérôme Pinot (site web personnel) . Évalué à 7.
NdM : le logiciel subversion datant de 2000, ça devait être initialement du CVS
Effectivement, c’était bien du CVS, et semble-t-il, les premiers commits significatifs datent de 2002.
# Quel dommage...
Posté par Didrik Pining . Évalué à 4.
Il manque… la chanson!
# Pendant ce temps-là chez GTK+
Posté par Sébastien Wilmet . Évalué à 9.
Ces derniers temps il y a beaucoup de refactoring dans GTK+, tant interne (donc qui n'affecte pas l'API) qu'externe (qui propose une nouvelle API et rendant obsolète l'ancienne).
Pour le refactoring interne, c'est surtout pour utiliser Clutter, permettant ainsi de profiter de l'accélération matérielle. Les développeurs se demandaient il y a quelques années si ce n'était pas mieux de recommencer un tout nouveau toolkit graphique basé sur Clutter, au lieu d'adapter GTK+. En fait les deux se produisent, puisqu'il y a la nouvelle bibliothèque Mx.
Il y a aussi pas mal de changements dans l'API, ce qui demande pas mal de boulot pour les développeurs d'applications.
Et à côté de ça, elementary a un support pour l'accélération graphique depuis le début, et l'API semble vraiment stable. Par contre point de vue fonctionnalités, je pense que GTK+ est plus complet.
Les autres bibliothèques des EFL (eio etc) semblent avoir le même but que la GLib, GIO, etc. De ce côté-là, je pense que GNOME a un gros avantage : GObject-introspection, qui permet d'utiliser n'importe quelle bibliothèque basée sur GObject dans un autre langage que le C, sans devoir créer et maintenir des bindings. Pour l'instant Python et Javascript sont supportés (et dans une certaine mesure Vala, mais GObject-introspection n'est pas encore tout à fait au point pour Vala).
Bref, la base de GNOME (GObject, GLib, GIO etc) est très bien, mais GTK+ se fait un peu vieux… Et pour les développeurs d'applications, c'est plus intéressant de se baser sur une API qui ne risque pas de changer d'ici un an ou deux.
[^] # Re: Pendant ce temps-là chez GTK+
Posté par cedric . Évalué à 10.
Alors tout d'abord, GTK+ est clairement plus complet et plus adapte que les EFL a l'heure actuelle pour le desktop. Il n'y a juste clairement pas photo. Il y a encore beaucoup de travail pour arriver a ce niveau.
Par contre dans le domaine de l'embarque et meme de l'embarque de riche (smartphone, tablette et netbook), il n'y a pas photo. Toutes les features necessaire sont presentes, et c'est donc la situation inverse, GTK+ doit rattraper les EFLs :-)
Enfin pour le dernier point, on travaille a un nouveau model objet qui devrait permettre de generer a la compilation les bindings optimeau pour les EFLs. Cela prendra un peu de temps pour etre utilise partout, mais l'API prend forme et a de serieux avantage. Note qu'il n'y aura aucun cassage de l'API existente !
[^] # Re: Pendant ce temps-là chez GTK+
Posté par fredix . Évalué à 4.
Il manque quoi pour développer une app en EFL pour le desktop ?
# E17 utilisable depuis de nombreuses années
Posté par olivierweb . Évalué à 5.
Quelqu'un sait sur quelles parties elles travaillent et pour quelle finalité ?
Une arlésienne que j'utilise depuis de nombreuses années. Et depuis 2006, je n'utilise que lui. C'est certain que j'hésite parfois à le mettre à jour à partir de SVN (même si c'est facile sous Gentoo), une révision boguée est toujours à craindre.
[^] # Re: E17 utilisable depuis de nombreuses années
Posté par Gabin . Évalué à -5.
Autant utiliser fluxbox ou Openbox car e17 n'apporte vraiment rien, même pas de gestion particulière des fenêtres.
E17 doit être au moins être de la classe de XFCE or, il n'a pas d'outils propres basés sur les EFL.
Ça reste un projet flou en fait.
[^] # Re: E17 utilisable depuis de nombreuses années
Posté par Zarmakuizz (site web personnel) . Évalué à 7.
Pour l'embarqué. Ils ont réussi à mettre les EFL sur un frigo.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: E17 utilisable depuis de nombreuses années
Posté par cedric . Évalué à 10.
Alors pour ce qui est de Samsung. Le travail concerne principalement l'amelioration du toolkit Elementary pour supporter un maximum de cas d'usage pour l'embarque (telephone, tv, appareil photo, camera, imprimante, tablette, netbook, …) ou desktop. Le deuxieme axe, c'est l'amelioration des performances aussi bien diminution de la consommation memoire que l'augmentation des performances du rendu GPU et CPU.
Je n'ai pas trop une vision actuelle de ce qui de Elementary. De ce que j'en sais, il y a du travail de fait pour ameliorer la navigation a la telecommande et ameliorer l'accessibilite du toolkit.
Par contre pour l'amelioration des performances, j'ai nettement plus d'information puisque c'est la partie sur laquelle je travaille. Tout d'abord les choses certaines, amelioration de la boucle de rendu principale pour la rendre plus maintenable et performante. On va la rendre asynchrone par defaut pour tous les backend (Ca veut dire que les EFL ne pourront a partir de la prochaine version plus tourner sans thread). Toutes les ressources graphiques seront aussi partage entre les applications (cela inclu image et glyph de font). Cela devrait permettre une moindre consommation memoire et un meilleur temps de demarrage. Ca c'est pour ce qui est sur.
Maintenant plus pour le cote recherche, un certain nombre d'algorithm de rendu son limite par la bande passante memoire. On est donc entrain d'experimente la compression des ressources graphiques du theme et des fonts avec un rendu direct. Cela pourrait augmenter la charge CPU, en diminuant la bande passante memoire consome, donc prendre moins de temps au final. La plus grosse question sera de voir si cela a un impact sur la consommation de batterie. On travaille aussi sur un moteur de rendu hybride GPU/CPU, car OpenGL n'est pas adapte a toutes les situations et il vaudrait mieux pour certain morceaux de l'image finale, passe par le CPU. Enfin pour ameliorer les performances, on espere pouvoir experimente avec un rendu par tile plus adapte a une meilleure utilisation du cache L1.
Enfin, ce que je rajoute dans la categorie optimisation, c'est le passage a une API et a notre propre modele objet. L'objectif est d'amener un certain nombre d'amelioration de debuggage d'abord et aussi d'amelioration des performances en optimisant l'allocation memoire. Contrairement au modele GObject par exemple, les principales contraintes de ce design sont d'avoir moins de code a ecrire qu'avant, avoir un meilleur layout memoire et une grande facilite de debuggage. Viendra aussi avec la generation automatique de binding, mais pas via introspection au runtime, mais par analyse a la compilation. Cela permettra de maintenir de bonne performance meme pour les bindings.
Quand a la finalite de ces travaux, pour Samsung, c'est Tizen.
[^] # Re: E17 utilisable depuis de nombreuses années
Posté par Maclag . Évalué à 10.
Peut-être que c'est juste parce que c'était pas la question, mais moi je me demande quand même:
Samsung ne bosse pas sur les applis qui vont avec?
Nan parce que les EFL, c'est super, on est tous d'accord.
E17, c'est super, on est tous d'accord.
Mais la très grande pauvreté de l'environnement applicatif autour, c'est un peu rédhibitoire.
Je sais que "ça va venir", "il faudra du temps", tout ça. En attendant, je vois beaucoup de "gadgets" ou d'applis relativement simples développées par des volontaires enthousiastes, mais rien d'un peu ambitieux (je ne sais pas moi: un équivalent à KDE-PIM, Evolution, ou simplement un navigateur web un peu complet, une suite bureautique?).
Des lecteurs multimédia, ça, y'en a! Maintenant y'a une table périodique des éléments. Mais sans vouloir rabaisser ou contrarier qui que ce soit, ça représente quoi dans les cas d'utilisation "de base"? Quel intérêt d'avoir un magnifique E17 sur son bureau, sa tablette et son mobile si c'est pour lancer immédiatement une appli parfaitement pas intégrée qui fait toute moche parce que c'est ça qu'on utilise pour de vrai au quotidien, et qui de plus implique qu'on charge une autre chiadée de bibliothèques en mémoire, et du coup paf, tout l'intérêt est perdu! J'aurais pu avoir plus léger avec un environnement 100% Gtk ou 100% Qt.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: E17 utilisable depuis de nombreuses années
Posté par cedric . Évalué à 8.
Alors effectivement ce n'etait pas la question :-)
Mais donc pour repondre a ta question, Samsung contribue effectivement a E17 comme application libre. Il doit dans le cadre du projet Tizen avoir un certain nombre d'application developpe par Samsung qui doive etre libere, client mail et autre petites applis comme ca. Mais j'avoue ne pas connaitre les details et savoir si ils vont liberes l'application qu'ils utiliseront sur leur terminal Tizen ou une version light par exemple. Donc de ce cote la, c'est clairement pour l'instant flou.
A titre d'information, ils ont une branche complete de Samsung mobile qui travaille avec les EFLs, ca doit representer environ mille personnes, quelques choses comme ca. Mais apres savoir ce qui finira en libre et qu'on pourra utiliser. J'avoue, je l'ignore. Et je pense que personne ne le sait.
Sinon side note, tu parles de quel desktop 100% QT ? Si tu fais reference a QT, ils ont tendances a reprendre pas mal de technologie a gauche a droite, donc en general, tu te retrouves avec la Glib de charge. Peut etre pas tout GTK ou GNOME, mais une bonne partie de dependence supplementaire.
J'avoue que je serais interresse de savoir si tu perds vraiment quelques choses en terme de consommation memoire en utilisant E17 avec des applications GTK/QT par rapport a l'environnement GNOME ou KDE. Je suis pret a parier que la reponse n'est pas celle que tu crois :-)
[^] # Re: E17 utilisable depuis de nombreuses années
Posté par lolop (site web personnel) . Évalué à 8.
Waouw
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: E17 utilisable depuis de nombreuses années
Posté par Maclag . Évalué à 6.
Euh, pour le bureau, la conso mémoire, on va dire que maintenant on s'en fout vu les ordis modernes. Je pensais plutôt aux tablettes et smartphone.
Et du coup, j'avais moins Gnome et KDE en tête que des trucs genre Maemo et Meego (ou voir ce que donne Plasma Active, mais je ne sais pas à quel point il est lourd).
[^] # Re: E17 utilisable depuis de nombreuses années
Posté par psychoslave__ (site web personnel) . Évalué à 4.
lol, moi j'ai un pc portable qui a un processeur moins puissant et autant de RAM que mon dernier « téléphone ».
[^] # Re: E17 utilisable depuis de nombreuses années
Posté par cedric . Évalué à 8.
Je ne suis pas du tout d'accord sur ce point la. La premiere raison, c'est que tu as certe beaucoup de memoire, mais sa latence et sa bande passante on faiblement augmente au cour du temps (a mettre en rapport avec la taille et avec la puissance du CPU qui elles ont suivi la loi de moore). Ce qui fait que aujourd'hui tres tres peu d'application utilise efficacement le CPU et passe leur temps a attendre la memoire pour bosser. Ca a des impacts sur la consommation de tes batteries. Plus longtemps tu attends dans un etat reveille, plus tu perds de batterie. Aussi dans des scenarios multi-seat le desktop a le meme probleme, CPU qui attend gentillement de recevoir ou pouvoir envoyer ses donnees.
Donc quand tu diminues ta consommation memoire meme au prix d'un plus gros effort de CPU, tu peux etre gagnant au final. C'est une des raisons pour lesquels, on va partager plus de donnees entre les applications, car sur certain cpu le cache est capable de detecter qu'on pointe sur la meme adresse physique. Donc plus de chance d'avoir les donnees dans le cache. Et c'est aussi pourquoi on experimente avec les techniques de compression light pour avoir plus de donnees en cache.
Meme aujourd'hui, moins tu utilises de memoire, mieux tu te portes…
Pour ce qui est de Maemo et Meego, a ma connaissance, leur UI n'a jamais ete libre et base sur une version modifie des widgets GTK/Qt, donc tu perds meme la portabilite des applications desktop. De ce point de vue la, un environnement Tizen/EFL, meme avec ses applis proprietaire est plus sympa, car au moins tu as la meme API sur le device que sur desktop. Mais globalement, tant que c'est proprio, ca n'a aucun interet !
Le projet vraiment interressant actuellement, c'est Mer/Plasma Active. Ils utilisent les technologies KDE/Qt et un design novateur pour faire un nouvel environnement. Il y a quelques bonnes idees. Malheureusement, la derniere fois que j'ai essaye, ca n'etait pas vraiment encore utilisable, stable et performant. On vera ce que ca donne sur leur tablette Vivaldi. Mais au moins chez eux, tout est libre et la barriere d'entre est assez basse pour faire des protos grace aux JavaScript et a QtQuick.
De mon point de vue, si le projet Tizen/EFL ne libere pas les applications, le projet Mer/Plasma Active a de grand chance de gagner le coeur de pas mal de fabricant chinois. Mais ils n'en sont pas encore la. Et la course est encore bien engage… Surtout qu'on a en tete Apple et Amazone sur le domaine des tablettes. Microsoft tente une arrive sur le marche. Donc c'est un environnement qui bouge beaucoup. Il y a encore beaucoup de possibilite et de voie qui n'ont pas encore ete explore…
[^] # Re: E17 utilisable depuis de nombreuses années
Posté par Jérôme Pinot (site web personnel) . Évalué à 10.
C'est pour ça qu'il a fallu une bonne Tizen d'années de développement.
# Sans oublier le plus important
Posté par Bayet Thierry . Évalué à 5.
Oui, bien sur, pour beaucoup, ce n'est qu'un détail, mais E17 ne signifie pas que c'est la 17 ème version stable, car sa numérotation est quand même enlightenment 0,17. Quand on sait combien Rasterman est un perfectionniste, et il a bien raison.
[^] # Re: Sans oublier le plus important
Posté par Maclag . Évalué à 6.
Y'a une roadmap pour la 1.0?
-----------> [ ]
[^] # Re: Sans oublier le plus important
Posté par cedric . Évalué à 4.
Non, par contre, on sait ce qu'on veut mettre dans la 0.18 :-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.