Internet : Epiphany va migrer vers du 100% WebKit
Posté par Étienne Bersac (Jabber id, page perso, ). Modéré le 02 avril 2008.
Depuis la version 2.21.4, Epiphany intègre un couche d'abstraction du moteur de rendu et deux backends pour le rendu : un basé sur Gecko et un basé sur Webkit. À l'avenir, il n'y aura ni couche d'abstraction ni multiple backend, Epiphany utilisera directement le port Gtk+ de Webkit.
Cette décision montre la liberté de GNOME après l'accord passé avec la fondation Mozilla, le 11 mars dernier, pour améliorer l'interopérabilité des deux projets.
![[en]](../images/en.png)
L'annonce sur le blog des développeurs (412 hits)-
Message d'un dév de Webkit (243 hits)
-
L'annonce cosignée par les développeurs d'Epiphany (222 hits)
> Lire la dépêche (88 commentaires, moyenne: 3,5).
Vous avez demandé le commentaire #919218.
Run by 
Cette page a été générée par Templeet en 0.1019s (dont 0.0218 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Re:
> de sorte que GNOME puisse se doter enfin d'une vrai API de rendu HTML pour yelp, devhelp, Evolution, Tomboy, etc. et définitivement désavouer gtkhtml et gecko.
Pourquoi désavouer gecko ?
Je pense qu'Epiphany fait une connerie de faire ça aujourd'hui.
Mozilla était en guerre contre IE. Mozilla a réussi, le standard web est le W3C et non IE. Le taux d'adoption doit être de 1/4 (à confirmer) toute plateforme confondue. On ne remercira jamais assez Mozilla d'avoir inversé les choses.
Maintenant (du moins petit à petit) Mozilla peut se concentrer sur d'autres aspects. Embarque gecko dans des applis, le marché des mobiles, etc.
Je n'ai pas eu l'impression qu'Epiphnay (ou des projets équivalent) a discuté en profondeur avec Mozilla.
Prenons acte. Je n'utilise pas Epiphany, mais c'est du très bon.
[^]Re: Re:
Le choix d'Epiphany est uniquement technique et en rien politique.
Le travail politique de la fondation Mozilla est admirable. Le travail technique est également très bon avec Firefox et Thunderbird.
Cependant, techniquement, la fondation mozilla n'assure que très très peu la possibilité d'utiliser Gecko dans des applis autres que Firefox. Un nombre incroyable de bugs d'Epiphany sont en fait des bugs de gecko et ne sont pas résolus dans Gecko car n'apparaissant pas dans Firefox et donc non prioritaire.
Parfois, un de ces bugs est résolu dans Gecko version de développement mais étant donné le process de release très lent, il faut parfois attendre 18 mois avant que la solution arrive enfin aux utilisateurs d'epiphany (par exemple le bug de la page qui "saute" quand on fait une recherche).
Rajoutons à cela que l'utilisation de Gecko est très compliquée (très peu parmi les dev Epiphany osent y toucher) et que, comme dit dans l'annonce, les bindings GtkMozEmbed ne sont pas maintenus. Ce n'est pas un hasard si Evolution utilise le très foireux GtkHtml et si très peu d'appli Gnome utilise un moteur de rendu html (devhelp). En choisissant un moteur de rendu qui peut devenir partie intégrante du projet Gnome, cela ouvre un tas de nouvelles perspectives.
Je pense qu'il faut voir l'annonce comme : "nous, développeurs de Epiphany, on veut se simplifier la vie donc on abandonne Gecko. Mais si qquelqu'un décide de maintenir le backend Gecko, les patchs sont les bienvenus."
[^]Re: Re:
> Le choix d'Epiphany est uniquement technique et en rien politique.
Je n'ai pas dit le contraire.
> Firefox. Un nombre incroyable de bugs d'Epiphany sont en fait des bugs de gecko et ne sont pas résolus dans Gecko car n'apparaissant pas dans Firefox et donc non prioritaire.
Webkit aura le même problème.
C'est un problème classique de "force en présence".
> En choisissant un moteur de rendu qui peut devenir partie intégrante du projet Gnome, cela ouvre un tas de nouvelles perspectives.
Gecko peut aussi devenir partie intégrante de Gnome. J'ai l'impression que c'est toi qui fait d'un problème technique un problème politique...
[^]Re: Re:
Webkit aura le même problème.
Pas tout à fait :
"Gecko n'est pas conçu pour être réutilisé par d'autre navigateur" et "GtkMozEmbed n'est plus maintenu"
alors que "Webkit est conçu pour être réutilisé"
De part sa conception, WebKit semble poser moins de soucis d'intégration dans une appli tiers, à plus forte raison si l'appli en question n'est pas le "leader".
MonoFrance
[^]Re: Re:
>Gecko n'est pas conçu pour être réutilisé par d'autre navigateur
C'est totalement faux ! Il y a des dizaines de logiciels qui embarquent gecko (je ne parle même pas de ceux qui sont basés sur XulRunner). eclipse, camino maemo, pour ne citer qu'eux.
Y a même des docs pour embarquer Gecko : http://developer.mozilla.org/en/docs/Gecko_Embedding_Basics
[^]Re: Re:
D'un coté, quand on voit les perfs de gecko sur maemo ...
[^]Re: Re:
Les perfs de Gecko sur Maemo viennent justement de s'améliorer... d'un facteur 5,9 :-D
http://www.0xdeadbeef.com/weblog/?p=349
[^]Re: Re:
Effectivement, en tant qu'utilisateur Maemo, cette nouvelle me réjouit au plus haut point ! Je suis déjà heureux d'avoir vu le navigateur passer de Opera à Mozilla.
Je crois que cette compétition Webkit/Gecko est vraiment une bonne chose pour les utilisateurs. Deux concurrents qui vont se surpasser rien que dans le monde du libre.
[^]Re: Re:
C'est pas parcque tu peux courrir sur une piste d'athlétisme avec des bottes qu'elles ont été conçues pour.
MonoFrance
[^]Re: Re:
HA Merde, et c'est maintenant que tu me le dis ... et moi qui me demandait pourquoi je perdais tous mes 100 mètres. :].
[^]Re: Re:
> Gecko n'est pas conçu pour être réutilisé par d'autre navigateur
Il l'est !
Seamonkey, Thunderbird, Galeon, Epiphany, liferea, etc le prouve largement.
Que ça sucks est possible. Que Webkit sucks moins est possible aussi.
[^]Re: Re:
Par exemple, liferea ne sait pas afficher les images/videos inclus dans un feed si on est connecté via un proxy :
http://sourceforge.net/tracker/index.php?func=detail&aid(...)
Les devs de liferea ne voient aucun moyen de contourner le problème avec Gecko. Or ce genre de trucs me semble vraiment basique pour un moteur de rendu embeded.
[^]Re: Re:
Ben un bug.
WebKit doit aussi avoir des bugs (ou des fonctionnalités manquantes). Et si WebKit n'arrive pas à faire un truc, je ne vais pas dire de suite que WebKit n'a pas été conçu pour.
[^]Re: Re:
le fait que ça se fait et que ça marche n'implique pas forcément que c'est conçu pour.
les flingues ne sont pas fait pour percer des murs et y faire passer des cables tv, pourtant y'en a qui utilisent leur flingue à cet usage.
[^]Re: Re:
Faut pas pousser à ce point.
Gecko a été conçu pour être réutilisé.
Je veux bien admettre que c'est mal foutu ou autre, mais Gecko a été conçu pour ça. C'est indiscutable.
[^]Re: Re:
non à la base gecko a été conçu pour netscape 6. c'est sa libération qui a permis son adoption ailleurs, mais ce n'était pas son but.
[^]Re: Re:
En fait il a été conçu pour Mozilla (la suite), elle même faites pour être la base de Netscape 6.
Mais c'est juste un détail, histoire de préciser que c'était libre avant d'être intégré à Netscape.
[^]Re: Re:
D'après wikipedia, le développement de Gecko a commencé en 1997 et avait pour objectif de remplacer le moteur de Netscape dès qu'il serait stable. Mozilla est né en 98, avec au passage le passage en open-source de Gecko. Netscape a décidé la même année d'intégrer le moteur dans la version suivante de Netscape ce qui sera effectif en 2000.
Après, savoir si Netscape avait dans l'idée dès 97 de mettre Gecko open-source lors de sa création, je sais pas...
MonoFrance
[^]Re: Re:
Gecko a été conçu pour être réutilisé.
Non. Le bon fonctionnement de gtkembedmoz est la dernière des priorités des développeurs. C’est déjà un miracle d’arriver à faire fonctionner quelque chose comme Epiphany dessus, et ça marche grâce à quantité de bidouilles immondes.
[^]Re: Re:
>Rajoutons à cela que l'utilisation de Gecko est très compliquée (très peu parmi les dev Epiphany osent y toucher)
Gecko est complexe, mais webkit aussi. Faut pas se leurrer, un moteur de rendu, c'est très compliqué. Si les dev d'epiphany n'osent même pas toucher Gecko, ils ne le feront pas non plus pour webkit. Ça demande des compétences en programmation beaucoup plus fortes que celles nécessaires à faire une interface à un moteur de rendu. Des mecs comme David Hyatt (l'un des core-developer de Webkit, et ex-mozillien), capable donc de toucher à webkit sans tout casser, ça ne se trouve pas à tout les coins de rues.
>Un nombre incroyable de bugs d'Epiphany sont en fait des bugs de gecko et ne sont pas résolus dans Gecko [...] si quelqu'un décide de maintenir le backend Gecko, les patchs sont les bienvenus.
Tes deux citations sont franchements paradoxales.
[+] [^]Re: Re: Re:
« En choisissant un moteur de rendu qui peut devenir partie intégrante du projet Gnome, cela ouvre un tas de nouvelles perspectives. »
Tu veux dire un service de rendu html et javascript comme Webkit l'est déjà sur Mac OS X ? Qui ferait le rendu des courriels, des pages webs, des widgets, etc ?
Je vais probablement être moinsé pour ça, mais je remarque que, quoi qu'on en dise, Apple a une nouvelle fois montré la voie :) Mac OS X, çaputc'estpaslibre mais c'est plutôt du bon boulot qui fait de bonne machine qui permet d'empiéter sur Microsoft comme Mozilla l'a fait dans le domaine du web. D'ailleurs, je profite pour répondre à une critique dans un autre commentaire concernant le côté libriste d'Apple qui serait loin d'être une seconde nature :
1. Ce n'est pas en boudant Apple alors qu'il entreprend une démarche ouverte sur le libre qu'on l'incitera à y aller.
2. Si Apple se fout tant de ses partenaires, pourquoi webkit se répand tant, au point que KDE a sabordé KHTML au profit de son fork Webkit, et pourquoi Epiphany suit le mouvement ?
Même si Apple était un Microsoft (ce qui est loin d'être prouvé) il vaut mieux avoir deux Microsofts rivaux à combattre qu'un seul deux fois plus gros. Alors un peu moins de jalousie et qu'on se réjouisse un peu du succès d'Apple, zut. LE libre n'a qu'a faire du boulot aussi bon et aussi bien intégré, vu le succés de l'EEEPC, ça a l'air de bouger enfin de ce côté là...
Citoyen moramarth
[^]Re: Re: Re:
> Je vais probablement être moinsé pour ça, mais je remarque que, quoi qu'on en dise, Apple a une nouvelle fois montré la voie
Hum, KDE le faisait avant Apple, après tout, webkit est un fork de khtml (qui existe depuis KDE 2.0).
[^]Re: Re: Re:
> Tu veux dire un service de rendu html et javascript comme Webkit l'est déjà
> sur Mac OS X ? Qui ferait le rendu des courriels, des pages webs, des
> widgets, etc ?
Non, comme KHTML l'est depuis encore plus longtemps sous KDE.
Ici c'est encore KDE qui montre la voie :-)
> au point que KDE a sabordé KHTML au profit de son fork Webkit,
Sauf que KDE n'a pas encore sabordé KHTML.
Et que la raison qui pousse tout le monde à utiliser Webkit c'est tout simplement les ressources mises dans Webkit.
5 développeurs de KHTML qui bosse de temps en temps sur leur temps libre
contre une trentaine de développeurs payés, chez Apple
!!!NOUVEAU!!!
[^]Re: Re:
Moi je suis utilisateur d'Epiphany et j'en suis déjà très content. Ne plus supporter le backend gecko c'est une chose mais avoir une couche d'abstraction me paraissait une très bonne idée.
Ça aurait permis à d'autres de maintenir le backend gecko, mais aussi dans l'avenir de pouvoir changer de moteur à souhait et facilement.
Debian Sid
[^]Re: Re:
Oui mais comme doubler les backends sans doubler l'équipe, c'est impossible.
[^]Re: Re:
C'est clair que l'utilisation de termes tels que "désavouer", "vrai api", ... est assez maladroite et déforce la tentative d'argumentaire un peu plus haut en teintant l'article d'un a priori anti-gecko peu constructif.
Reste qu'il ne faut pas perdre de vue que ce sont les mots de l'auteur de la dépêche et non les mots des développeurs d'Epiphany ou de Gnome: le manque de qualité rédactionnelle de la dépêche ne doit pas devenir prétexte à mettre en doute le bien fondé d'un passage à WebKit (l'annonce sur le blog des développeurs est heureusement de bien meilleure qualité)