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. Voici les principales motivations de ce choix :
- Maintenir 2 backends est du gâchis de temps et de fonctionnalités spécifique à l'un ou l'autre backend
- Gecko a un cycle de développement long
- GtkMozEmbed n'est plus maintenu
- Gecko 2.0 ne convainc pas et viendra dans longtemps
- Webkit est conçu pour être réutilisé
- Webkit est conçu pour être porté en réutilisant le plus possible le système hôte (Gtk+, cairo, pango, gstreamer, etc.)
- Webkit est efficace (rapidité, conformité, fonctionnalité, etc.)
- Webkit/Gtk+ va opter pour un cycle régulier de 6 mois
- Webkit est éligible pour bien d'autres utilisations dans GNOME
A contrario, Webkit a des désavantages :
- L'accessibilité demande encore du boulot (c'est actuellement trop dépendant de l'architecture)
- Webkit/Gtk+ est encore jeune (pas encore de tests de régression automatiques, etc.)
- L'API GObject est encore incomplète (notamment l'accès à DOM)
- Webkit/Gtk+ n'est pas encore optimisé
Epiphany devrait passer totalement à Webkit pour la 2.24 ou la 2.26 suivant les disponibilité. Gageons que cette annonce va aider le projet Webkit/Gtk+ pour accélérer sa maturation, 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.
Aller plus loin
- L'annonce sur le blog des développeurs (3 clics)
- Message d'un dév de Webkit (1 clic)
- L'annonce cosignée par les développeurs d'Epiphany (1 clic)
# le choix dans la date...
Posté par B16F4RV4RD1N . Évalué à 2.
À partir du moment où internet utilise des standards vraiment respectés, en soit cela ne devrait pas poser de problème, et m'encouragera peut-être à utiliser epiphany un peu plus souvent...
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: le choix dans la date...
Posté par jerome bagattin . Évalué à 5.
[^] # Re: le choix dans la date...
Posté par cosmocat . Évalué à 1.
http://www.bide-et-musique.com/song/902.html
# Re:
Posté par IsNotGood . Évalué à 5.
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:
Posté par ploum (site web personnel, Mastodon) . Évalué à 10.
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."
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Re:
Posté par IsNotGood . Évalué à 2.
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:
Posté par TImaniac (site web personnel) . Évalué à 0.
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".
[^] # Re: Re:
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
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:
Posté par benoar . Évalué à 3.
[^] # Re: Re:
Posté par Tristan Nitot (site web personnel) . Évalué à 4.
http://www.0xdeadbeef.com/weblog/?p=349
[^] # Re: Re:
Posté par ploum (site web personnel, Mastodon) . Évalué à 4.
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.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Re:
Posté par TImaniac (site web personnel) . Évalué à 8.
[^] # Re: Re:
Posté par Samaty Tramo . Évalué à 2.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 2.
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:
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
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.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Re:
Posté par IsNotGood . Évalué à 0.
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:
Posté par Psychofox (Mastodon) . Évalué à 3.
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:
Posté par IsNotGood . Évalué à 1.
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:
Posté par Psychofox (Mastodon) . Évalué à 8.
[^] # Re: Re:
Posté par gnu_castor . Évalué à 2.
Mais c'est juste un détail, histoire de préciser que c'était libre avant d'être intégré à Netscape.
[^] # Re: Re:
Posté par TImaniac (site web personnel) . Évalué à 2.
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...
[^] # Re: Re:
Posté par Jar Jar Binks (site web personnel) . Évalué à 5.
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:
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
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:
Posté par moramarth . Évalué à -2.
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à...
[^] # Re: Re: Re:
Posté par wismerhill . Évalué à 4.
Hum, KDE le faisait avant Apple, après tout, webkit est un fork de khtml (qui existe depuis KDE 2.0).
[^] # Re: Re: Re:
Posté par Gof (site web personnel) . Évalué à 5.
> 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
[^] # Re: Re:
Posté par barmic . Évalué à 6.
Ça aurait permis à d'autres de maintenir le backend gecko, mais aussi dans l'avenir de pouvoir changer de moteur à souhait et facilement.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Re:
Posté par liberforce (site web personnel) . Évalué à 3.
[^] # Re: Re:
Posté par ragoutoutou . Évalué à 4.
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é)
# et KHTML ?
Posté par tanguy_k (site web personnel) . Évalué à 10.
KHTML va t'il mourir définitivement ?
WebKit est il désormais 100% ouvert aux développeurs extérieurs ?
Sympa de voir que DCOP a donné naissance à DBUS et KHTML, WebKit
AHMA les technos KDE sont définitivement des bonnes technos...
[^] # Re: et KHTML ?
Posté par Franck Routier (Mastodon) . Évalué à 5.
à moins que ta foi ne connaisse de limite dans le temps :)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: et KHTML ?
Posté par rewind (Mastodon) . Évalué à 9.
DBus a été adopté très rapidement dans KDE en remplacement de DCOP alors qu'il a mis plus de temps à intégrer GNOME me semble-t-il. De mon point de vue, par rapport à freedesktop.org, je dirais que les dev GNOME pousse beaucoup leurs propres techno dans freedesktop (je pense à GStreamer ou PolicyKit par exemple qui sont fortement GNOMisé), techno souvent en concurrence avec des technos KDE. Et pourtant, ça n'empêche pas les dev KDE de les adopter. Les dev de KDE ont une approche plus pragmatique et moins politique que GNOME je pense.
[^] # Re: et KHTML ?
Posté par windu.2b . Évalué à 10.
Surtout depuis que Trolltech a annoncé que Qt 4.4 contiendra WebKit. Donc cela garantit :
* La portabilité de WebKit, garanti par la portabilité de Qt (Trolltech y attachant une grande importance, vuq ue c'est quand même leur gagne-pain) ;
* Le soutien d'une autre entreprise (avec Apple, qui l'utilise pour Safari) dans le développement/entretien de WebKit.
Et donc tout ceci rendant le moteur moins dépendant d'un seul navigateur (ce qui semble être reproché à Gecko vis-à-vis de Firefox).
Par contre, merci pour ce journal : je viens de découvrir que WebKit avait un portage pour Gtk+ :-)
J'ignorais totalement ce détail, croyant (à tort semble-t-il) que Webkit étaitt trop lié à Qt pour pouvoir un jour rejoindre des projets Gnome.
[^] # Re: et KHTML ?
Posté par Psychofox (Mastodon) . Évalué à 2.
J'ignorais totalement ce détail, croyant (à tort semble-t-il) que Webkit étaitt trop lié à Qt pour pouvoir un jour rejoindre des projets Gnome.
ça fait pourtant un moment que tu peux compiler epiphany avec webkit svn !
[^] # Re: et KHTML ?
Posté par windu.2b . Évalué à 2.
Mais bon, étant plutôt pro-KDE, je ne m'intéresse pas plus que ça aux technos/softs sous Gnome... Du moins, je me tiens un peu informé mais je ne creuse pas spécialement la question...
[^] # Re: et KHTML ?
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
Que ce soit présent dans le svn ne voulait pas non plus dire que c'était très stable. D'ailleurs, cette option n'est pas activée par défaut et Epiphany est alors compilé avec le support Gecko.
Cela dit, c'est une bonne nouvelle quand même parce qu'il y a certains bugs gênants (comme ne pas pouvoir retirer un certificat sous Epiphany).
[^] # Re: et KHTML ?
Posté par 태 (site web personnel) . Évalué à 5.
[^] # Re: et KHTML ?
Posté par Narishma Jahar . Évalué à 1.
[^] # Re: et KHTML ?
Posté par med . Évalué à 1.
J'ai l'impression que certains développeurs de KHTML ont développé un profond sentiment de rejet vis-à-vis de Webkit et ne veulent même pas en entendre parler. J'ai été le témoin il y a quelques jour du massacre d'un pauvre étudiant intéressé par un SoC ayant mentionné l'intégration de webkit à KDE. Il a eu le malheur de ne pas être au courant de certains antagonismes. Il s'est moitié fait incendier dans le canal par un des développeurs de KHTML. Je sais bien que la relation avec Webkit a été particulièrement tendue au début grâce à l'attitude particulièrement peu constructive d'Apple mais j'ai cru comprendre que cela avait bien changé et qu'un certain nombre de développeurs de KHTML avaient migré vers Webkit générant une certaine rancœur. Au final j'ai la sensation que le problème n'est pas vraiment technique mais situé au niveau de l'ego. Pour ma part si konqueror supporte webkit dans KDE 4.1 j'utiliserai celui-là. Il me semble que plasma utilise déjà Webkit dans la version de développement d'ailleurs.
# Persch
Posté par liberforce (site web personnel) . Évalué à 2.
[^] # Re: Persch
Posté par Thomas Debesse (site web personnel) . Évalué à 7.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Persch
Posté par Laurent J (site web personnel, Mastodon) . Évalué à -1.
>Gecko n'est pas conçu pour être réutilisé par d'autre navigateur
Ce qui est absolument faux.
[^] # Re: Persch
Posté par Robert Palmer (site web personnel) . Évalué à 8.
Pensez à l'environnement avant d'imprimer ce commentaire - Please consider the environment before printing this comment
[^] # Re: Persch
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
# Bonne décision
Posté par liberforce (site web personnel) . Évalué à 10.
1. D'avoir un nouveau navigateur (même s'il n'est pas des plus utilisés, epiphany est tout de même le navigateur internet officiel de GNOME) utilisant webkit.
2. De renforcer encore un peu webkit, afin qu'il ait encore plus de poids sur le marché, rendant le respect des standards encore plus importants (plutôt que du "j'autorise IE et Firefox").
3. Cela montre que GNOME n'est pas marié à la Fondation Mozilla
4. Cela montre aussi que quand KDE fait du bon boulot, GNOME sait le reconnaitre :-)
et enfin (last but not least)...
5. Avec Firefox et Epiphany, il y a deux solutions en GTK+ avec deux moteurs de rendu différents, et ça c'est très très bien.
[^] # Re: Bonne décision
Posté par seginus . Évalué à 6.
En effet, avec l'ampleur qu'à pris Firefox, on se retrouve plus ou moins avec des sites juste testé sur les deux (certain site sorte assez mal sous konqueror bien que c'est un des navigateus dont le moteur est le plus à jour au niveau des normes (et peut-être aussi moins laxiste que d'autres), sans parlé des des sites qui maintenant bloque l'accès aux navigateurs autres que IE et Firefox.
Ceci ce trouve d'ailleurs dans un autre domaine : les systèmes l'exploitation eux-même. Si BSD pouvait bien se développer sur le desktop (j'ai pas vraiment de traduction à ce mot), cela permettrai de favorisé de plus en plus la diffusion des sources ou des spécification de matériel.
En effet on se trouve avec de plus en plus de matériel avec des pilotes pour windows et linux (comme les cartes ati) ou des programmes sur les deux (skype, googleearth pour lequel je trouve ça abusé, et d'autres).
Lorsque qu'il n'y avait qu'un système d'utilisé, c'était assez simple on faisait juste tout pour cette plateforme.
Maintenant qu'il y en a 2, c'est encore jouable, mais ça a quand même un coût.
Quand il y en aura dix, il faudra penser à voir les choses autrement et réellement pensé à l'interopérabilité de façon générale et non entre deux concurents.
[^] # Re: Bonne décision
Posté par ragoutoutou . Évalué à 3.
C'est certain, à condition que les 10 aient une part de marché suffisante pour ne pas être catalogués par les développeurs web comme "les 10 trucs marginaux qui marchent moins bien"...
Je préfèrerais voir les navigateurs "alternatifs" taper dans les parts de marché d'Internet Explorer que dans celles de Firefox (qui constitue à l'heure actuelle le seul réel contre-pouvoir à l'hégémonie I.E.sur le web)...
[^] # Re: Bonne décision
Posté par seginus . Évalué à 2.
[^] # Re: Bonne décision
Posté par Gof (site web personnel) . Évalué à 6.
Konqueror n'utilise pas webkit, mais KHTML
Webkit est un fork du KHTML de 2002 (6 ans!!!) et depuis les deux moteur ont chacun beaucoup évolués.
[^] # Re: Bonne décision
Posté par liberforce (site web personnel) . Évalué à 1.
[^] # Re: Bonne décision
Posté par Gof (site web personnel) . Évalué à 4.
A partir de là (donc pas avant KDE 4.1), certaines applications pourraient choisir d'utiliser QtWebkit à la place de KHTML.
Il y a déjà, dans une branche, un KPart QtWebkit qui peut être utilisé dans Konqueror à la place de KHtmlPart.
Mais Webkit est beaucoup moins intégré à KDE (et même à Qt) que KHTML.
Par exemple, dans webkit, les widgets présents dans les pages web (<input/>, bar de défilements) ne sont plus des widget Qt alors qu'ils l'étaint dans KHTML.
[^] # Re: Bonne décision
Posté par Julien . Évalué à 6.
Il existe aussi du code (par exemple la version de TRUNK, futur 4.1 de plasma) qui dépend de webkit.
Cet état de fait est du à l'existance de deux camps chez les développeurs KDE (trois si on compte aussi le camps de ceux qui s'en foutent).
Ceux qui poussent pour l'utilisation de webkit.
Je pense notamment à un ex développeur de khtml embauché chez Trolltech qui a participé à l'intégration de webkit dans Qt. Son principal argument est qu'utiliser webkit permettra un comportement similaire bug pour bug à Safari et donc la compatibilité d'un plus grand nombre de pages.
C'est aussi le cas de Aaron Seigo, l'actuel président de KDE e.V. C'est lui qui a fait le choix d'utiliser webkit dans plasma. Sa position est plus pragmatique et son principal argument est que webkit fonctionne bien, qu'il est intégré à Qt et que KDE ne pourra jamais mettre autant de ressources dans le développement de KHTML que celles qui sont mises dans webkit.
Dans le camps des contre, ce sont surtout les développeurs actuels de KHTML.
Il faut noter qu'ils ont tout d'abord eu des relations très tendues lors des débuts de webkit. Apple n'a parlé de ce fork que bien après l'avoir lancé. Pendant tout ce temps, il n'ont pas collaboré avec les développeurs de KHTML. Ils ne fournissaient au début que le code source (comme légalement nécessaire avec la LGPL) mais pas les commits indépendemment les uns des autres ... Bref, ils ont été loin d'être coopératif.
Les arguments de ce camp concernent donc premièrement cet aspet politique, utiliser webkit au lieu de KHTML revient à laisser les choix concernant un composant important de KDE à des entités externes. Ils soulignent aussi que les release de webkit ne correspondront pas à celles de KDE. Ainsi, il ne sera plus possible de sortir une nouvelle version mineure de KDE en cas de bug dans le moteur HTML. Enfin, puisque KHTML et webkit se sont séparé il y a maintenant pas mal de temps, passer à webkit signifierait abandonner tout le travail fait entre temps sur KHTML et revenir en arrière sur certaines fonctionalités.
Bref, le débat est loin d'être tranché et déchaîne pas mal les passions au sein de KDE. On peut cependant se féliciter que ce débat reste relativement technique et qu'il se cantonnne à ceux qui ont effectivement un choix à faire sans dégénérer en un troll stérile entre les deux camps.
# les buts divergent (et divergent, c'est trop)
Posté par Germain Saval . Évalué à 6.
À l'inverse Gecko est une plateforme complète (XUL et tout et tout), qui sert de base au développement d'autres applications. C'est un peu contradictoire avec l'objectif de légèreté et d'interface native d'Epiphany, non ? Tout ça me semble logique et pragmatique, finalement. Ou alors, c'est le meilleur poisson d'avril que j'ai vu...
[^] # Re: les buts divergent (et divergent, c'est trop)
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 4.
Pas plus que webkit. Je crois que tu confond Gecko et XulRunner (qui embarque en plus de gecko, toutes les apis genre gestion d'extension, le toolkit d'interfaces etc, bref, tout ce qui fait la plateforme).
XUL, ce n'est qu'un dialect XML affiché via une feuille de style CSS et utilisant en trés grande partie XBL (un autre dialecte XML) pour l'api des composants d'interface.
Bref, supporter XUL, c'est supporter l'affichage du XML (ce qui est exactement pareil que d'afficher du HTML, c'est le même code dans le moteur de rendu), les langages CSS et XBL.
Et finalement, webkit sait faire en grande partie tout ça (XML+CSS) et saura tout faire plus tard puisqu'il est prévu un support de XBL2 dans Webkit (je rappel que David Hyatt, core-dev de webkit et ex-mozillien, est l'inventeur de XBL et celui qui a fait les premières implémentation de XBL dans Gecko, donc je ne me fait pas de souci, webkit supportera à coup sûr XBL). Et alors, à partir de là, supporter un XUL like sera une étape bien maigre pour arriver au niveau de Gecko.
[^] # Re: les buts divergent (et divergent, c'est trop)
Posté par Germain Saval . Évalué à 1.
Je ne confonds pas, je simplifie un peu... Les buts affichés (pour WebKit¹ et Gecko²) me semblent assez différents. En particulier, certains choix technologiques de Gecko favorisant la généricité au détriment de la performance sont dus à Mozilla puis Firefox...
C'est pas un reproche, c'est juste que des objectifs différents aboutissent à des résultats différents. (Vous entendez ce bruit ? C'est La Palice qui fait des sauts carpés dans sa tombe.)
¹ http://webkit.org/projects/goals.html
² http://developer.mozilla.org/en/docs/Gecko_FAQ
# Troll à gogo
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 4.
> Gecko n'est pas conçu pour être réutilisé par d'autre navigateur
Bon ça je l'ai déjà dit dans d'autres commentaires.. C'est totalement faux. C'est peut être assez complexe à embarquer, mais Gecko est tout de même conçu pour être embarqué. Y a une doc et tout. D'ailleurs, si il ne l'était pas, on se demande comment a fait epiphany pendant des années, et comment font les autres logiciels qui embarquent gecko.
Ensuite, je n'ai pas vu cet argument dans les liens que tu as cité. Bref, pure supposition infondée de ta part. Du pur troll
> Gecko 2.0 ne convainc pas
Autant je peux les comprendre sur les changements d'api qu'occasionnera Gecko2, autant ils ont oublié d'omettre une chose : l'objectif de Gecko 2 est justement de faciliter son embarquement (dont notamment dans des softs déstiné aux mobiles), d'accroitre encore plus ses performances etc.. Bref, Gecko 2 correspondra tout à fait à leurs exigences.
> Webkit est conçu pour être réutilisé
Là encore, je ne sais pas où tu a lu cet argument dans les liens cités. Gecko aussi est fait pour être réutilisé...
> Webkit est conçu pour être porté en réutilisant le plus possible le système hôte (Gtk+, cairo, pango, gstreamer, etc.)
Gecko aussi. Gecko repose aussi sur cairo, gtk et cie... D'ailleurs l'un des liens le précise. Bref, ce n'est pas un avantage à webkit.
> Webkit est efficace (rapidité, conformité, fonctionnalité, etc.)
rapidité : gecko aussi. Des tests ont montrés d'ailleurs que la version 1.9b5 surpassait webkit au niveau javascript notamment (avec une suite de tests créée par les dev de webkit !). Au niveau conformité et fonctionnalité, c'est kifkif (les tests acid étant loin d'être une réference exhaustive en la matière)
> Webkit est éligible pour bien d'autres utilisations dans GNOME
En quoi Gecko ne le serait pas ?
[^] # Re: Troll à gogo
Posté par rewind (Mastodon) . Évalué à 2.
[^] # Re: Troll à gogo
Posté par Gof (site web personnel) . Évalué à 1.
qu'est-ce qui empèche les développeur de Epiphany de corriger eux même les bugs ?
[^] # Re: Troll à gogo
Posté par Psychofox (Mastodon) . Évalué à 2.
[^] # Re: Troll à gogo
Posté par Gof (site web personnel) . Évalué à 3.
Ce n'est que parce que des persones hors de Apple ont décider de s'y plonger que il peut être réutilisé autre part. (et que Apple a bien voulu ouvrir son développement, après un long développement fermé)
Et je ne crois pas que les développeurs de chez Apple en ont plus à faire des bug de Epiphany que les développeur de Mozilla.
[¹] "apple-centrique" est peut-être plus correct
[^] # Re: Troll à gogo
Posté par briaeros007 . Évalué à 1.
C'est quand même drole de voir cet argument, alors que juste avant, on avait "gecko a été conçu pour être embarqué : la preuve, il a été embarqué et il y a même une doc.
Je paris que pour webkit il a aussi déjà été réutilisé, et qu'il y a une doc qqpart.
Comme quoi, un poid , deux mesures.
[^] # Re: Troll à gogo
Posté par Gof (site web personnel) . Évalué à 2.
(Et la doc de webkit... bhe il y a le code source :-) )
[^] # Re: Troll à gogo
Posté par briaeros007 . Évalué à 1.
Perso je n'en sais rien, mais que tu dise que "webkit c'est faux il a pas été conçu pour être réutilisé", et que tu dise absolument rien alors que rien ne permet d'affirmer que gecko a été conçu pour ça
Tu ne pense pas ?
[^] # Re: Troll à gogo
Posté par Gof (site web personnel) . Évalué à 2.
[^] # Re: Troll à gogo
Posté par briaeros007 . Évalué à 1.
Mais , je me suis peut être mal exprimé, ce que je trouve bizarre, c'est que quand laurent le dis à propos de gecko, tu ne dis rien, et quand on dis la meme chose pour webkit, la tu nous explique comme quoi il a pas été conçu pour ça.
Encore une fois, je n'en sais rien, mais ça fait quand même un poid (le contenu des phrases sont identiques pour gecko ou webkit), deux mesures (tu t'attarde principalement sur webkit et pas du tout sur gecko).
Je voulais juste faire remarquer ça.
[^] # Re: Troll à gogo
Posté par Gof (site web personnel) . Évalué à 3.
Les développeurs d'Epiphany ont sans doute pleins de raisons valables de choisir Webkit au détriment de Gecko.
Mais « Gecko est Firefoxo-centré et Mozilla n'a que faire d'Epiphany et de GNOME. » n'en est pas une, car (quand bien même ce serait vrai) pour webkit c'est pareil.
[^] # Re: Troll à gogo
Posté par Thomas Douillard . Évalué à 2.
[^] # Re: Troll à gogo
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 8.
Peut-etre tout simplement les dev de Gnome ont également rencontré le meme soucis. Un projet libre, au sens licence, ne signifie pas hélas "ouvert" au sens projet.
[^] # Re: Troll à gogo
Posté par Gof (site web personnel) . Évalué à 1.
https://linuxfr.org/~Gof/25882.html#891696
Ah tiens, justement avec notre contributeur de Mozilla préfé qui prétends que le développement d'un logiciel doit se faire dans un cercle restreint de développeurs approuvés. (j'extrapole) :-)
[^] # Re: Troll à gogo
Posté par liberforce (site web personnel) . Évalué à 3.
[^] # Re: Troll à gogo
Posté par Erwan . Évalué à 1.
Pourquoi attendre que leurs patchs soient upstream pour les utiliser ?
[^] # Re: Troll à gogo
Posté par ploum (site web personnel, Mastodon) . Évalué à 6.
C'est une dépendance très forte et plutôt inconfortable. Les dev ont cru que XULrunner serait la solution mais, d'après ce que j'ai vu passé, XULrunner est moins maintenu que Firefox et modifier Epiphany pour utiliser XULrunner à la place de Firefox s'est révélé très très dur.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Troll à gogo
Posté par Camille_B . Évalué à 4.
[^] # Re: Troll à gogo
Posté par imalip . Évalué à 4.
http://packages.qa.debian.org/e/epiphany-browser/news/200602(...)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Troll à gogo
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Camino n'est pas écrit en XUL. Eclipse n'est pas écrit en XUL. Le moteur d'indexation experimental de Google qui repose sur gecko n'est pas écrit en XUL. On pourrait en trouver plein des exemples comme ça.
>À l'origine, Gecko c'étais Mozilla 1.0. Il a été rendu plus ou moins réutilisable, mais c'est pas fait pour.
http://developer.mozilla.org/en/docs/Gecko_Embedding_Basics
>Suffit de voir comment Gecko rend les combobox lorsqu'on clique dessus: c'est plus du Gtk+
Non, tout est définit en CSS, reposant en particulier sur la propriété -moz-appearance (appearance en CSS3), propriété à travers laquelle Gecko va interroger le toolkit graphique de la plateforme pour savoir comment dessiner les widgets. Dans FF2, c'est pas GTK+ effectivement, mais GTK2 (je ne sais pas si c'est la même chose ou pas)
[^] # Re: Troll à gogo
Posté par Jar Jar Binks (site web personnel) . Évalué à 2.
Ils s’arrachent les cheveux. D’où l’abandon.
Gecko aussi est fait pour être réutilisé...
Non, trois fois non. Gecko est conçu pour être le moteur de Firefox. Le reste, c’est de la seconde zone.
Gecko aussi. Gecko repose aussi sur cairo, gtk et cie... D'ailleurs l'un des liens le précise. Bref, ce n'est pas un avantage à webkit.
Webkit dispose d’une API entièrement basée sur GObject, qui permet de l’intégrer directement au système de classes de GNOME. Alors que Gecko nécessite l’utilisation de couches d’interface tordues en C++ et d’une quantité de code de glu qui ne fait que croître avec le temps. Quant à parler de réutilisation de GTK+ Gecko, c’est à peu près autant le cas que pour Openoffice. Utilisé oui, mais très mal utilisé, d’où les lenteurs terribles du port X11 par rapport au port Windows, par exemple.
En quoi Gecko ne le serait pas ?
Parce que Gecko est une usine à gaz, et que contrairement aux idées reçues, les développeurs de GNOME cherchent à alléger leurs applications.
# Firefox 3
Posté par Idzi . Évalué à -2.
[^] # Re: Firefox 3
Posté par Camille_B . Évalué à 4.
Firefox 3 est un très bel outil, mais Epiphany diffère suffisamment de lui pour avoir une réelle raison d'être.
[^] # Re: Firefox 3
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 2.
Ceci dit je regrette quand même qu'Epiphany (oui je l'utilise dans KDE) abandonne Gecko, parce que c'était le seul moyen de tester mes sites dans Gecko sans attendre 30 secondes que Firefox se réveille... Mais ceci dit du côté standards et utilisation je trouve que c'est une bonne décision, Gecko s'avouant incapable de régler leurs bugs à long terme (y'a qu'à regarder le look des éléments de formulaire ou l'impossibilité de styler <legend>, etc etc.).
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
# Donc, en comptant les points...
Posté par MiniMoi . Évalué à 2.
- Android va l'utiliser, donc on peut compter sur Google pour faire des ameliorations
- l'iPhone, qui est l'appareil mobile avec le meilleur navigateur (selon moi)
- KDE
- Apple (OK, deja dit, mais je parle du Desktop la)
- Apparamment, Gnome aussi
Pour etre un utilisateur de WebKit, je suis ravi par les performances, mais il reste a mon avis un tres gros point noir: il y a plus de leaks que dans Gecko (celui de FireFox 3), beaucoup plus... Une longue session de GMail n'est pas possible.
J'ai teste recemment avec Safari 3.1 et WebKit nightly sur Mac OS X 10.5. A chaque fois que j'ouvrais un mail (toujours le meme) et que je retournais a la boite de reception (avec les raccourcis clavier), +2-3Mo en consommation memoire !
Et vu le travail qui a ete necessaire pour traquer tous les petits leaks et la fragmentation dans Gecko, on peut supposer qu'arriver au meme niveau que FireFox 3 prendra du temps... beaucoup de temps.
[^] # Re: Donc, en comptant les points...
Posté par windu.2b . Évalué à 4.
Parce qu'une fuite mémoire sur une utilisation desktop, ça "passe" encore... Mais sur du matos embarqué, ça le fait de suite beaucoup moins !
Donc, face aux contraintes matérielles, il y a fort à parier que ces deux-là fassent ce qu'il faut pour reboucher des trous, c'est dans leur intérêt.
[^] # Re: Donc, en comptant les points...
Posté par Prosper . Évalué à 2.
[^] # Re: Donc, en comptant les points...
Posté par Julien . Évalué à 2.
[^] # Re: Donc, en comptant les points...
Posté par Erwan . Évalué à 4.
* Android, on sait pas ce que ca va donner en terme de parts de marche
* Mac, ca pese pour environ 5% des utilisateurs d'internet et beaucoup utilisent Firefox
* KDE et Gnome: Linux sur le desktop n'a que quelques pourcents
Donc a mon avis, avec les parts de marche de Firefox, Gecko va rester le principal moteur apres les divers IE pour pas mal de temps.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.