Raster (Carsten Haiztler), principal développeur de E17, 8 Septembre 2008 :
"Well - it's been a while. I'll make this short. I don't work for Openmoko anymore - that didn't work. Definitely turned out to be a non-working thing for me, so I resigned, and that was effective August 31, 2008. I'm now a free man.
http://www.rasterman.com/index.php?page=News
Et effectivement, le développement de E17 semble s'accélérer depuis cette annonce.
Pour suivre le développement de E17 en temps réel, ça se passe ici
http://trac.enlightenment.org/e/browser/trunk?order=date&des(...)
Pour télécharger le script d'installation et de mise de mise à jour de E17
http://omicron.homeip.net/projects/#easy_e17.sh
Cette liste est bien active :
Archives mailing lists (enlightenment-users)
http://sourceforge.net/mailarchive/forum.php?set=custom&view(...)
Journal E17, ça avance
27
sept.
2008
# Le futur
Posté par justt . Évalué à 1.
[^] # Re: Le futur
Posté par cedric . Évalué à 3.
Je pense que tu parles de l'openmoko. Si c'est le cas, tu voudrais mettre quel autre window manager qui offre les meme fonctionnalite et la meme consomation de ressource ?
Franchement le seul interet de QTopia par rapport aux EFL, c'est quand meme juste que les applis sont deja ecrite. Maintenant tu peux a mon avis faire des choses nettement plus joli et anime avec les EFL que tu ne peux le faire avec QTopia. Mais ca demande aussi du travail...
[^] # Re: Le futur
Posté par justt . Évalué à 1.
[^] # Re: Le futur
Posté par tanguy_k (site web personnel) . Évalué à 4.
"juste" ? mais c'est énorme comme avantage !
L'intérêt de Qt c'est à terme un paquet de logiciels. Par exemple KDE4 est en train d'être porté sur Maemo.
EFL c'est peut être super cool, super beau ect... mais malheureusement ca risque de rester anecdotique comme librairie, trop lié a un WM + écrasé entre GLib/GTK+ et Qt.
tu peux a mon avis faire des choses nettement plus joli et anime avec les EFL que tu ne peux le faire avec QTopia
J'aimerais bien voir un truc fait avec EFL qui ne soit pas faisable avec Qt...
[^] # Re: Le futur
Posté par cedric . Évalué à 1.
Pour ce qui est de QT, est-ce que tu peux faire ce genre d'appli facilement : http://calaos.fr/pub/video/calaos_home_new2.ogg
[^] # Re: Le futur
Posté par tanguy_k (site web personnel) . Évalué à 5.
C'est possible http://www.youtube.com/watch?v=f2qBUCghAJw&feature=relat(...)
C'est la demo qui est livree avec Qt sous Windows/Linux/MacOSX
(voila un post qui explique la genese de la demo Qt http://labs.trolltech.com/blogs/2007/04/11/qt-demo/ )
J'imagine que EFL doit etre plus simple/puissant puisqu'il existe le projet QEdje http://dev.openbossa.org/trac/qedje (mon raisonnement sans etre aller voir le code : si QEdje existe, ca doit etre que Edje doit avoir un avantage par rapport a Qt)
Dans Qt-4.5 il est prevu une API pour faire des animations GUI.
D'autres videos sur Youtube a propos des possibilités graphiques de Qt
http://www.youtube.com/watch?v=TLbO73oQaeU&feature=relat(...)
http://www.youtube.com/watch?v=uxQFY4mp_E0&feature=relat(...)
http://www.youtube.com/watch?v=uwE_UIHSWnY&feature=relat(...)
Qt est peut etre un peu moins doué pour les GUI avec des effets dans tous les sens. Gardons à l'esprit que Qt evolue tres vite et que ce manque va etre comblé rapidement.
En attendant, Qt dispo de fonctionnalites moins bling-bling mais nettement plus interessantes au quotidien qu'aucun autre framework ne propose : SQL, WebKit, XML, OpenGL, scripting, networking, multimedia, SVG, Windows/Linux/MacOSX...
[^] # Re: Le futur
Posté par cedric . Évalué à 10.
Tout d'abord, les EFL sont bases sur un canevas qui enregistre l'etat dans lequel sont les primitives graphiques et qui lors d'une demande de rendu ne vas afficher que la difference entre l'etat precedent et le nouvel etat. Ensuite la boucle de rendu n'est appele que lorsque l'application n'a plus rien a faire. Ainsi il n'y a pas de flickering ou d'objet qui apparaisse vide ou quoi que ce soit comme anomalie graphique lors de toute phase de demarrage, animation ou autre tache qui change le layout de l'application. Il n'y a donc pas besoin de mettre en place un benchmark qui va desactiver les effets qui ralentiront ton application. Ceux-ci ne seront afficher que si le systeme le peut au moment ou l'application le demande.
C'est entierement dynamique et ca s'adapte automatiquement a la charge de ton systeme au court du temps. Enfin le but des EFL a toujours ete d'etre extremement optimise sur tous les plans possible: consomation memoire, bande passante, ressource CPU. Ce qui fait qu'aujourd'hui l'engine software est plus rapide que la version OpenGL pour certaine configuration.
Enfin Edje est la bibliotheque de theme qui utilise Evas (la lib de canvas), Ecore (la lib d'evenement) et Eet (la lib de serialisation et de stockage) pour proposer un systeme permettant de themer et de changer le layout des applications, widgets tout en gardant les performances necessaire a des systemes embarques. Et effectivement, c'est une des fonctionnalites les plus interressantes des EFL que l'ont ne trouve pas dans Gtk ou Qt et qu'il est logique qu'ils la reprennent. Dans le lien que je te fournis, il est facile pour un designer/graphiste de changer les animations, le layout de l'application sans toucher a une seule ligne de C.
Pour ce qui est de Qt, ou de Gtk, ils sont a ma connaissance tous les deux entrain de se diriger vers le meme systeme de pipeline graphique que celui utilise par les EFL. Mais ca va prendre du temps avant d'avoir quelque chose du meme niveau de performance et de fonctionnalite.
Enfin pour ce qui est du reste du framework, les EFL, ca reste du C, donc pour le SQL par exemple, il est plus simple d'utiliser directement l'API de SQLite plutot que de reinventer une abstraction entre les deux qui ne serviraient pas reellement a grand chose vu la simplicite d'une tel API. La meme chose va pour quasiment tout le reste sauf peut-etre WebKit qui est la fonctionnalite qui manque le plus aux EFL, mais necessiterait bien trop de ressource pour la faire fonctionner.
Enfin pour ce qui est de la portabilite des EFL, je crois qu'on a pas trop a ce plaindre, on a des engines natif pour Linux/Windows/Windows CE/MacOsX, et les EFL fonctionnent sur des machines tres minimaliste comme des ARM a moins de 100Mhz avec des ecrans noir&blanc (genre ebook) jusqu'a des PC de bureau multi coeur et des giga de ram. Et par experience personnelle, les EFL tournent plus que correctement la ou meme QTopia fait des OOM. C'est d'ailleur pour ca que je travaille maintenant sur les EFL.
[^] # Re: Le futur
Posté par tanguy_k (site web personnel) . Évalué à 7.
intuitivement j'ai mis le lien car ca me paraissait bien compliqué pour une simple demo :)
L'intro sur les EFL explique aussi en quoi c'est different de l'approche "traditionnel"
http://homepages.pathfinder.gr/kazanaki/contrib/ch03.html
pour le SQL par exemple, il est plus simple d'utiliser directement l'API de SQLite plutot que de reinventer une abstraction entre les deux qui ne serviraient pas reellement a grand chose vu la simplicite d'une tel API.
L'intérêt d'avoir une abstraction c'est de pouvoir changer de moteur SQL en changeant simplement un paramètre + d'avoir une API consistante avec le reste. C'est quand même un bel avantage, meme rien que pour des tests.
J'utilise Phonon qui est abstraction multimedia qui a beaucoup ete decrie a ces debuts et le resultat est pourtant assez magnifique : 4 lignes de code et je peux lire une video ou un mp3 Et je peux changer d'engine suivant l'OS ou ce que je veux faire. Tout ca en gardant une API simple et consistante avec le reste du framework.
on a des engines natif pour Linux/Windows/Windows CE/MacOsX
Ca c'est intéressant ! je savais pas du tout.
Et ils communiquent pas trop la dessus... impossible de trouver un lien
J'ai remarque un truc : les EFL c'est sur le site web de Enlightenment, les snapshots sortent en meme temps que celles de Enlightenment, le SVN est le meme ect... Y'a pas mieux pour faire l'amalgame dans la tete des gens.
Et question conne : pourquoi diable avoir codé un nouveau toolkit ? c'etait pas possible d'integrer toutes ces idees dans GTK+ (Qt c'est plus difficile car controller par Trolltech) ? (bon ok changer le canvas de GTK+ ca doit pas etre simple...)
J'ai toujours vu Rasterman comme une grande gueule "je vais tous vous niquer avec mon truc" :) alors que j'ai souvent lu que imlib1 était un gros boulet qu'a du se trainer GNOME pendant un petit moment.
En tout cas les marketeux devraient etre content. A mon epoque, mes marketeux cheries me prenaient le chou pour foutre des effets partout avec des themes plus moches les uns que les autres dans l'application :/
[^] # Re: Le futur
Posté par cedric . Évalué à 4.
J'avoue toujours avoir eu du mal sur les abstractions de moteur SQL, car il y a souvent de legere difference dans leur support du langage SQL lui meme et on finit toujours par plus ou moins avoir un truc qui fait pouf dans un coin.
Par contre, je n'ai jamais utilise Phonon, et je n'en connais ni les capacite, ni les limite. Mais les EFL fournissent une lib multimedia (Emotion) qui cree un objet qui peut etre manipule comme n'importe quel autres objets (deplacement, redimensionnement, changement de couleur, ...). Une vieille video de cette lib en action: http://www.vergenet.net/~raster/files/rage2.avi . Il existe actuellement des backend gstreamer, xine et un backend vlc est entrain d'etre integre.
Par contre, tu mets bien le doigt sur un probleme du projet Enlightenment, peu de monde prend le temps de communiquer dessus. Alors forcement, les capacites et les choses que l'ont peut faire avec son assez peu connu.
Sinon pourquoi avoir recoder un nouveau toolkit... En fait, on n'a pas recoder un toolkit, mais un canevas. On est parti du point oppose des toolkit comme GTK ou Qt, en commencant par realiser un pipeline graphique efficace puis en construisant les outils dont on avait besoin au dessus. Mais le coup d'ecriture d'un toolkit au dessus des EFL est assez faible et il est completement envisageable de porter par exemple GTK dessus, si quelqu'un y voit un interet.
D'ailleur c'est tellement simple d'ecrire un toolkit au dessus, qu'on doit en avoir environ 5 au dessus avec des philosophies differentes (de tete, il y a EWL, ETK, E, Guarana et Alarm). Et d'un point de vue personnel, je trouve le concept de toolkit au sens GTK+ et QT assez limitant dans ce que l'on peut faire graphiquement. Mais bon, ca c'est le genre de discussion qu'il vaut mieux avoir accoude a un bar.
Il faut vraiment voir que la ou les EFL excelle, c'est lorsqu'on veut faire du soft pour un terminal genre media player ou des jeux en fait. Un traitement de texte ou un tableur en EFL, je doute que ca ai de l'interet...
[^] # Re: Le futur
Posté par tanguy_k (site web personnel) . Évalué à 3.
Ca fait souvent pouf dans un coin, donc oui il vaut mieux tester avant de changer de backend mais en l'occurrence si pas d'abstraction alors il faut tout re-ecrire si jamais on veut changer, c con qd meme...
Par contre, je n'ai jamais utilise Phonon, et je n'en connais ni les capacite, ni les limite.
C'est encore jeune mais c'est vraiment bien, je code (un peu moins en ce moment, manque de temps) des backends pour Phonon http://code.google.com/p/phonon-vlc-mplayer/ + un player multimedia
et il n'y a pas que moi qui le dit : http://www.valdyas.org/fading/index.cgi/hacking/phonon.html
Amarok 2 utilise desormais Phonon
Phonon en lui meme est mature, en revanche les differents backends beaucoup moins mais ca va venir car il y a plein d'acteurs : Trolltech, Amarok/KDE, des devs de VLC...
C'est un peu le meme probleme qu'avec les abstractions SQL, ca fait souvent pouf dans un coin mais c'est quand meme vachement mieux que d'etre lie a vie (ou presque) a un seul moteur (c'est par exemple le cas de SMPlayer)
Il faut vraiment voir que la ou les EFL excelle, c'est lorsqu'on veut faire du soft pour un terminal genre media player ou des jeux en fait. Un traitement de texte ou un tableur en EFL, je doute que ca ai de l'interet...
Avoir dans les applications quelques effets graphiques facon EFL et une gestion des themes poussée, ca peu etre pas mal. On a bien du bling-bling dans le desktop (Compiz) alors pourquoi pas un peu dans les applications aussi.
Si Trolltech inclu un ersatz de EFL dans Qt, quelle sera la future des EFL ? un marche de niche ? un truc experimental et uniquement utilise dans la sphere E17 ?
[^] # Re: Le futur
Posté par cedric . Évalué à 2.
C'est une excellente question (d'ailleur, GTK integrera a terme forcement le meme genre de fonctionnalite). C'est un peu le principe du libre, la competition permet a tout le monde de progresser. Donc pour le libre, c'est de toute facon une bonne chose.
Maintenant pour E17, c'est sur que deja on n'a pas les moyens de Trolltech et Nokia, donc va vraiment falloir etre bon, si on veut continuer a attirer du monde. Donc effectivement, le marche de niche, ce sera l'embarque low cost, la ou QT et GTK ne peuvent pas tourner sans de tres tres gros travaux d'optimisation. Et surement les machines deja en prod dont on ne pourra que mettre le soft a jour.
[^] # Re: Le futur
Posté par tanguy_k (site web personnel) . Évalué à 2.
Le futur c'est peut etre ca
http://dev.openbossa.org/trac/qedje
Qt/GTK + des bouts de EFL
En tout cas si vous voulez que la sauce prenne, y'a pas de miracle : communiquer, communiquer, communiquer !
Faire un wiki, deja rien que transformer ca
http://homepages.pathfinder.gr/kazanaki/contrib/ en wiki, ca serait pas mal (la ca fait un peu HOWTO de 1996...)
Informer les gens sur le fait que c'est multiplateforme, ecrire des tutoriels (ou au moins pointer sur du code simple qui fait des trucs simples) et dans le futur essayer de faire une jolie doc a la Qt (http://doc.trolltech.com/ ), mettre des screenshots sur Wikipedia...
Faire en sorte qu'une recherche sur Edge ou EFL donne quelque chose sur Google.
Faire en sorte que le projet soit vraiment independant de Enlightenment.
Parceque malheureusement la visibilite des EFL est completement inexistante :/
Sans communication, c'est evident, c'est sur a 100%, ca va jamais prendre (deja qu'en communiquant c'est pas evident...)
[^] # Re: Le futur
Posté par tanguy_k (site web personnel) . Évalué à 2.
Il s'est avere que c'est un franc succes et ils ont decide il y a quelques jours de creer un wiki oriente utilisateurs : UserBase http://dot.kde.org/1221824063/
Les tutorials pour developper avec KDE sont sur TechBase http://techbase.kde.org/Development/Tutorials
Faire en sorte qu'une recherche sur Edge ou EFL donne quelque chose sur Google
En meme temps c'est normal ca s'appelle Edje et non Edge et le 1er lien donne ca http://wiki.enlightenment.org/index.php/Edje :p
[^] # Re: Le futur
Posté par Mathieu Schroeter (site web personnel, Mastodon) . Évalué à 1.
??? Ecore, Evas, Edje, ... y a quoi de trop lié à un WM dans toutes les libs? Je travail justement dans un projet basé sur les EFL et je ne me soucie pas du tout du WM de E17 (qui lui ne m'intéresse pas).. C'est le WM qui est lié au EFL, comme Gnome est lié à GTK ou KDE est lié à Qt..
Ou alors je n'ai pas compris ta remarque?
[^] # Re: Le futur
Posté par tanguy_k (site web personnel) . Évalué à 2.
Faut le prendre dans le sens "marketing" du terme. Tout comme GTK+ etait lie a GIMP en son temps. Et je pense que ca peut etre un handicap.
Typiquement, DR17 est percu comme une sorte de "DukeNukem Forever" et par conséquent j'imagine que la grande majorite des gens pensent la meme chose des EFL.
[^] # Re: Le futur
Posté par vincent LECOQ (site web personnel) . Évalué à 3.
# debian
Posté par M . Évalué à 7.
[1] par exemple deb http://ftp.fr.debian.org/debian ../project/experimental main contrib non-fre
e
# Raster à openmoko, ça n'aura pas duré
Posté par zecrazytux (site web personnel) . Évalué à 3.
Il devient surtout mature, une release stable ne devrait pas trop tarder...
Ce qui m'étonne c'est que Raster ne soit pas resté bien longtemps chez OpenMoko.
Même pas un an !
Je ne vois pas ça comme un bon signe pour openmoko. (Dans le sens ou si raster se casse, c 'est que ça sent le roussi)
Y a t'il d'autres projets d'environnements open source pour matériel mobile basé sur les EFL/enlightenment ?
[^] # Re: Raster à openmoko, ça n'aura pas duré
Posté par Maclag . Évalué à 4.
Je ne sais pas pourquoi Raster s'est barré exactement, mais c'est peut-être qu'on lui a fait comprendre que le tout EFL ce sera pas pour tout de suite parce que ça va être trop long à développer, alors en attendant, ce sera QT ou GTK pour les applis et le reste on verra plus tard.
C'est dommage, parce que ça aurait pu donner un super coup de pub aux EFL, mais en même temps, ça n'a jamais été super évident sur les sites d'OpenMoko qu'il y a des bouts d'E17/EFL dedans...
[^] # Re: Raster à openmoko, ça n'aura pas duré
Posté par cedric . Évalué à 3.
[^] # Re: Raster à openmoko, ça n'aura pas duré
Posté par Victor STINNER (site web personnel) . Évalué à 4.
http://laforge.gnumonks.org/weblog/linux/openmoko/index.html
C'est l'ancien mainteneur de Netfilter (parefeu Linux). J'ai cru comprendre qu'il bossait sur le réseau dans OpenMoko.
# Poll: Duke Nukem forever ou E17 ?
Posté par Xavier Maillard . Évalué à 10.
Quoique à ce rythme, Hurd pourrait être prêt avant tout le monde, c'est dire...
# Merci
Posté par Mildred (site web personnel) . Évalué à 1.
J'ai installé E17 avec le script easy_e17.sh et ça marche bien, c'est joli, on peut configurer ... Ça manque encore un peu de thèmes (je trouve le thème par défaut en fait un peu trop) mais c'est tout de même agréable.
C'est avec ce genre de projets qu'on se rend compte que le libre n'est pas si en retard que ça par rapport à des bureaux comme Mac OS X. On, voit une réelle recherche d'esthétique et ça fait du bien.
Bon, par contre, avec le plugin bling pour avoir la composition, c'est toujours incompatible avec xv pour l'accélération vidéo. Et de temps en temps E17 freeze :( Mais à part ça, c'est très bien. Bravo.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.