Articles précédents : Internet
- [42] Les serveurs de TuxFamily vont déménager en Islande
- [22] La Quadrature du Net - Citoyens contre un Internet Big Brother
- [3] Interlug-fr fait peau neuve
- [40] L'hébergeur TuxFamily appelle les adeptes du libre à soutenir leur initiative
- [1] Derniers jours pour intervenir sur le forum "Ecole et Internet"
- [23] Création de l'entreprise « Mozilla Messaging »
- [13] Drupal 6 est sorti
- [13] Mozilla fait dans le social
- [9] Installer/configurer/exploiter Bind 9.4.x
- [119] Le W3C met en route le premier brouillon de HTML 5
Liens connexes
- L'annonce sur le blog des développeurs (486 hits)
- Message d'un dév de Webkit (287 hits)
- L'annonce cosignée par les développeurs d'Epiphany (266 hits)
Dépêche modérée par
Dépêche éditée par
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 (486 hits)-
Message d'un dév de Webkit (287 hits)
-
L'annonce cosignée par les développeurs d'Epiphany (266 hits)
> Lire la suite (88 commentaires, moyenne: 3,5). [dépêche : 1861 caractères]
- 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.
le choix dans la date...
si ce n'est pas un poisson pas frais (quelle idée d'annoncer cela à ce moment ? c'est pour cela que j'ai un peu de mal à y croire), et malgré le fait que je trouve toujours un peu dommage d'abandonner une option alors que les 2 existent déjà et sont déjà implémentées, je peux comprendre que supporter les 2 moteurs prennent des ressources de développement.
À 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...
"C’est un grave danger et seuls les imbéciles l’ignoreront, jusqu’au jour où il sera trop tard"
---------
Les dalles brillantes c'est moche et nul
-
[^]Re: le choix dans la date...
-
[^]Re: le choix dans la date...
Posté par cosmocat () le 02/04/2008 à 09:41. (lien). Évalué à 1.jolie musique aussi :)
http://www.bide-et-musique.com/song/902.html
-
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:
Posté par ploum (page perso, ) le 02/04/2008 à 08:55. (lien). Évalué à 10.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:
Posté par IsNotGood () le 02/04/2008 à 09:17. (lien). Évalué à 2.> 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:
Posté par TImaniac (Jabber id, page perso, ) le 02/04/2008 à 10:25. (lien). Évalué à 0.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".-
[^]Re: Re:
Posté par Laurent J (page perso, ) le 02/04/2008 à 10:54. (lien). Évalué à 5.>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:
Posté par benoar (Jabber id, ) le 02/04/2008 à 13:13. (lien). Évalué à 3.D'un coté, quand on voit les perfs de gecko sur maemo ...
-
[^]Re: Re:
Posté par Tristan Nitot (page perso, ) le 02/04/2008 à 13:57. (lien). Évalué à 4.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:
Posté par ploum (page perso, ) le 02/04/2008 à 14:21. (lien). Évalué à 4.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:
Posté par TImaniac (Jabber id, page perso, ) le 02/04/2008 à 19:16. (lien). Évalué à 8.C'est pas parcque tu peux courrir sur une piste d'athlétisme avec des bottes qu'elles ont été conçues pour.
-
[^]Re: Re:
Posté par Samaty Tramo (page perso, ) le 03/04/2008 à 02:04. (lien). Évalué à 2.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:
Posté par IsNotGood () le 02/04/2008 à 13:38. (lien). Évalué à 2.> 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:
Posté par ploum (page perso, ) le 02/04/2008 à 14:18. (lien). Évalué à 2.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:
-
-
[^]Re: Re:
Posté par PsychoFox () le 02/04/2008 à 14:27. (lien). Évalué à 3.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:
Posté par IsNotGood () le 02/04/2008 à 14:39. (lien). Évalué à 1.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:
Posté par PsychoFox () le 02/04/2008 à 15:14. (lien). Évalué à 8.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:
Posté par gnu_castor (Jabber id, ) le 03/04/2008 à 03:50. (lien). Évalué à 2.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:
Posté par TImaniac (Jabber id, page perso, ) le 03/04/2008 à 09:31. (lien). Évalué à 2.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...
-
-
-
[^]Re: Re:
Posté par Jar Jar Binks (page perso, ) le 04/04/2008 à 12:34. (lien). Évalué à 5.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:
Posté par Laurent J (page perso, ) le 02/04/2008 à 10:41. (lien). Évalué à 2.>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:
Posté par moramarth () le 07/04/2008 à 18:15. (lien). Évalué à -2.« 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:
Posté par wismerhill (page perso, ) le 07/04/2008 à 19:03. (lien). Évalué à 4.> 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:
Posté par Gof (Jabber id, page perso, ) le 07/04/2008 à 19:03. (lien). Évalué à 5.> 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
-
-
-
[^]Re: Re:
Posté par Barret Michel (page perso, ) le 02/04/2008 à 09:44. (lien). Évalué à 6.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:
Posté par liberforce (Jabber id, page perso, ) le 02/04/2008 à 10:48. (lien). Évalué à 3.Oui mais comme doubler les backends sans doubler l'équipe, c'est impossible.
-
-
[^]Re: Re:
Posté par ragoutoutou () le 02/04/2008 à 10:26. (lien). Évalué à 4.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é)
et KHTML ?
La question que l'on peut se poser, et qui a surement de multiples raisons, est pourquoi de plus en plus de projets adoptent WebKit et n'ont pas adopté KHTML à l'époque ? KHTML est/était-il trop liée à Qt pour être adopté ?
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 () le 02/04/2008 à 08:53. (lien). Évalué à 5.s/définitevement/décidément
à moins que ta foi ne connaisse de limite dans le temps :)
-
[^]Re: et KHTML ?
Posté par Étienne Bersac (Jabber id, page perso, ) le 02/04/2008 à 09:19. (lien). Évalué à 4.Ave,
KDE4 se tourne vers Webkit. KDE est souvent mieux conçu, mais trop en interne et c'est dommage. On voit bien peu de retour de de KDE dans freedesktop.org :( Au final, DBus et Webkit se sont fait un peu sans les dévs de KDE. Ils ne s'en soucis qu'après-coup.
Mes deux ¢.
Étienne--
E Ultreïa !-
[^]Re: et KHTML ?
Posté par rewind () le 02/04/2008 à 10:03. (lien). Évalué à 9.Ce n'était pas mon impression.
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 (Jabber id, page perso, ) le 02/04/2008 à 09:36. (lien). Évalué à 10.Même KDE se tourne vers WebKit maintenant.
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 () le 02/04/2008 à 09:54. (lien). Évalué à 2.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.
ça fait pourtant un moment que tu peux compiler epiphany avec webkit svn !-
[^]Re: et KHTML ?
Posté par windu.2b (Jabber id, page perso, ) le 02/04/2008 à 10:16. (lien). Évalué à 2.Oki, ben je l'ignorais :-)
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 (Jabber id, page perso, ) le 02/04/2008 à 13:27. (lien). Évalué à 2.Oui, enfin, l'option n'est disponible qu'avec la version d'Epiphany de Gnome 2.22...
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 ?
-
-
-
-
[^]Re: et KHTML ?
Posté par Narishma Jahar () le 02/04/2008 à 12:17. (lien). Évalué à 1.KHTML ne va nulle part. Il est toujours développé dans KDE et à ma connaissance sera supporté pour toute la série des KDE 4.x.
-
[^]Re: et KHTML ?
Posté par med (page perso, ) le 02/04/2008 à 17:17. (lien). Évalué à 1.C'est un avis personnel qui n'engage que moi et qui est basé sur les listes de diffusion et sur IRC.
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
C'est Christian Persch pas "Perche" ! Un modéro pourrait corriger la news svp ?
-
[^]Re: Persch
Posté par Thomas DEBESSE (page perso, ) le 02/04/2008 à 11:04. (lien). Évalué à 7.Perche, c'est pour coller au premier avril peut-être :p.
--
† In te confirmátus sum ex útero : de ventre matris meæ tu es protéctor meus.
-
[+] [^]Re: Persch
Posté par Laurent J (page perso, ) le 02/04/2008 à 11:06. (lien). Évalué à -1.Et corriger ça aussi
>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 (page perso, ) le 02/04/2008 à 19:09. (lien). Évalué à 8.Effectivement, avec IceWeasel ça fait deux /o\
-
[^]Re: Persch
Posté par Jar Jar Binks (page perso, ) le 04/04/2008 à 12:37. (lien). Évalué à 1.Non, c’est un constat objectif de comment les développeurs de Gecko axent leur développement. L’important pour eux, c’est de faire marcher Firefox, et le reste de toute façon est moins bien que l’extraaaaaordinaire Firefox, il est donc inutile de s’escrimer à le supporter.
-
-
[^]Re: Persch
Posté par Étienne Bersac (Jabber id, page perso, ) le 02/04/2008 à 16:37. (lien). Évalué à 2.Je présente mes plus plates excuses.
--
E Ultreïa !
Bonne décision
Je ne suis pas un expert, mais je trouve que la décision est plutôt bonne. Le moteur de rendu d'IE est très répandu, Gecko l'est pas mal à présent, grâce à firefox, mais webkit restait pour l'instant cantonné à Safari et Konqueror. A un moment où Safari commence à apparaître sous Windows, une telle décision permet:
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 () le 02/04/2008 à 13:30. (lien). Évalué à 6.Le deuxième point est je trouve le plus important. Et j'aimerai le voir ailleurs.
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 () le 02/04/2008 à 14:37. (lien). Évalué à 3.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.
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
-
-
-
[^]Re: Bonne décision
Posté par Gof (Jabber id, page perso, ) le 02/04/2008 à 13:47. (lien). Évalué à 6.> mais webkit restait pour l'instant cantonné à Safari et Konqueror.
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 (Jabber id, page perso, ) le 03/04/2008 à 11:18. (lien). Évalué à 1.KDE ne devait pas adopter webkit ? Ou c'est uniquement à partir de KDE 4 ? Désolé pour la boulette alors...
-
[^]Re: Bonne décision
Posté par Gof (Jabber id, page perso, ) le 03/04/2008 à 13:41. (lien). Évalué à 4.QtWebkit no sortira en version stable que avec Qt4.4 (dans pas longtemps normalement)
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 () le 03/04/2008 à 14:20. (lien). Évalué à 6.L'état actuel des choses est le suivant : webkit sera intégré dans Qt 4.4 (dont dépendra KDE4) mais le moteur utilisé par konqueror reste KHTML.
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)
J'ai l'impression que les objectifs de Webkit correspondent mieux aux buts d'Epiphany. Webkit a pour objectif de faire un moteur XHTML, rien qu'un moteur XHTML. Ils ont tout conçu pour leur principal client, le browser natif Safari pour Mac OS X. Ça correspond assez bien au positionnement d'Epiphany pour Gnome.
À 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 (page perso, ) le 02/04/2008 à 11:34. (lien). Évalué à 4.>Gecko est une plateforme complète
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 (Jabber id, ) le 03/04/2008 à 19:09. (lien). Évalué à 1.> Je crois que tu confonds Gecko et XulRunner
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
Franchement, cette news est vraiment un bon troll tout poilu, surtout ne reflete pas vraiment ce qui est dit dans les pages des liens.
> 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 () le 02/04/2008 à 13:49. (lien). Évalué à 2.Derrière tous ces "trolls", je pense qu'il faut voir le reproche principal qui n'est qu'en filigrane : Gecko est Firefoxo-centré et Mozilla n'a que faire d'Epiphany et de GNOME.
-
[^]Re: Troll à gogo
Posté par Gof (Jabber id, page perso, ) le 02/04/2008 à 14:12. (lien). Évalué à 1.Mais gecko est libre, non ?
qu'est-ce qui empèche les développeur de Epiphany de corriger eux même les bugs ?-
[^]Re: Troll à gogo
Posté par PsychoFox () le 02/04/2008 à 14:30. (lien). Évalué à 2.ça demande peut-être plus de travail tout simplement.
-
[^]Re: Troll à gogo
Posté par Gof (Jabber id, page perso, ) le 02/04/2008 à 14:57. (lien). Évalué à 3.Et webkit est safari-centrique¹ à l'origine.
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 () le 02/04/2008 à 15:18. (lien). Évalué à 1.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.
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.--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Troll à gogo
Posté par Gof (Jabber id, page perso, ) le 02/04/2008 à 15:37. (lien). Évalué à 2.En fait, webkit à pas été conçu pour pour être réutilisé :-)
(Et la doc de webkit... bhe il y a le code source :-) )-
[^]Re: Troll à gogo
Posté par briaeros007 () le 02/04/2008 à 16:32. (lien). Évalué à 1.En fait, webkit à pas été conçu pour pour être réutilisé :-)
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 ?--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Troll à gogo
Posté par Gof (Jabber id, page perso, ) le 03/04/2008 à 13:48. (lien). Évalué à 2.Jammais je n'ai affirmé, ni même suggéré que gecko avait été conçu pour être réutilisé. Tu dois pas répondre à la bonne personne.
-
[^]Re: Troll à gogo
Posté par briaeros007 () le 03/04/2008 à 16:00. (lien). Évalué à 1.c'est effectivement laurent qui l'a dis.
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.--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Troll à gogo
Posté par Gof (Jabber id, page perso, ) le 03/04/2008 à 17:22. (lien). Évalué à 3.C'est parce que je connais Webkit, et je ne connais pas Gecko.
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 () le 02/04/2008 à 14:34. (lien). Évalué à 2.Ptete qu'ils n'ont pas que ça à faire.
-
[^]Re: Troll à gogo
Posté par Johann Ollivier-Lapeyre (page perso, ) le 02/04/2008 à 15:23. (lien). Évalué à 8.Ben ça aide aussi d'avoir un compte SVN/CVS... Je me souviens d'un trol^^^topic sur kde-devel ou la constatation était faite qu'un guru kde n'avait jamais réussi à avoir son compte chez mozilla, malgré ses compétences, alors que chez KDE, c'est relativement aisé.
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.--
----------------------------------------------------------------
KDE - Kopete - Oxygen - KDEgames-
[^]Re: Troll à gogo
Posté par Gof (Jabber id, page perso, ) le 03/04/2008 à 17:36. (lien). Évalué à 1.En effet... voir aussi ce troll dans mon précédent journal:
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 (Jabber id, page perso, ) le 03/04/2008 à 11:22. (lien). Évalué à 3.Tu n'as pas lu les liens. On y lit que les devs d'epiphany en ont marre d'attendre des mois une release qui inclut le patch qu'ils ont fournit des mois avant. Le cycle de release de Gecko, à ce que j'ai compris, c'est "quand c'est prêt" (feature-based). Webkit est time based, et sera sur un cycle de 6 mois comme GNOME, facilitant le boulot d'epiphany.
-
[^]Re: Troll à gogo
Posté par Erwan (page perso, ) le 04/04/2008 à 20:15. (lien). Évalué à 1.Je comprends ca, mais pourquoi les devs d'Epiphany ne pourraient pas appliquer leurs patchs quand ils compilent Epiphany ?
Pourquoi attendre que leurs patchs soient upstream pour les utiliser ?-
[^]Re: Troll à gogo
Posté par ploum (page perso, ) le 05/04/2008 à 16:44. (lien). Évalué à 6.Je peux dire une bêtise mais Epiphany n'utilise pas son propre Gecko embarqué. Epiphany utilise Firefox. La preuve est que Epiphany dépend de Firefox sur Debian ou Ubuntu.
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.-
[^]Re: Troll à gogo
Posté par Camille_B (Jabber id, page perso, ) le 07/04/2008 à 12:48. (lien). Évalué à 4.Hum, sur Debian (sid) Epiphany n'est plus dépendant de Firefox, mais bien de xulrunner. Et il me semble que sur Ubuntu non plus, mais je ne peux pas vérifier.
-
[^]Re: Troll à gogo
Posté par imalip (page perso, ) le 07/04/2008 à 13:05. (lien). Évalué à 4.Ca fait meme 2 ans que c'est le cas :
http://packages.qa.debian.org/e/epiphany-browser/news/200602(...)--
"While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal
-
-
-
-
-
-
-
[^]Re: Troll à gogo
Posté par Étienne Bersac (Jabber id, page perso, ) le 02/04/2008 à 17:00. (lien). Évalué à 10.Ave,
> C'est peut être assez complexe à embarquer, mais Gecko est tout de même conçu pour être embarqué.
Sauf qu'au final, les applis qui utilisent Gecko sont écrite en XUL. Comme si Gecko (avec XUL) étais plus proche de la plateforme de développement que du moteur à utiliser dans n'importe quelle applis. Où est libgecko ?
> Gecko aussi est fait pour être réutilisé...
À l'origine, Gecko c'étais Mozilla 1.0. Il a été rendu plus ou moins réutilisable, mais c'est pas fait pour. Concrètement, Epiphany a du mal à tirer partie de toutes les fonctionnalités face à Firefox.
> Gecko 2 correspondra tout à fait à leurs exigences.
Je suis certains que Gecko 2 sera bien meilleur :) mais visiblement, l'équipe d'Epiphany est un peu réticente. Je n'ai pas d'avis là dessus.
> Gecko repose aussi sur cairo, gtk et cie...
Gecko ne le fait pas autant que Webkit. Suffit de voir comment Gecko rend les combobox lorsqu'on clique dessus: c'est plus du Gtk+ ! Gecko progresse dans ce sens, mais on est loin du compte. Quand est-ce que XUL sera une sorte de Glade ponté avec du DOM/Javascript !
>> Webkit est efficace (rapidité, conformité, fonctionnalité, etc.)
>
> rapidité : gecko aussi.
Dire que Webkit est efficace ne signifie pas que Gecko ne l'est pas, mais qu'il est candidat à le remplacer (contrairement à gtkhtml).
D'une manière générale, il ne faut pas voire le choix de webkit comme un anathème jeté sur Gecko. Gecko est très bien et c'est grâce à lui qu'IE recule. Pour ma part, je serait très heureux d'avoir enfin une vrai raison d'avoir firefox installé sur ma machine : tester mes sites web avec Gecko :)
Enfin, il faut célébrer la naissance d'un nouveau troll : webkit-gecko ! Pourquoi nier son plaisir :)
Cordialement,
Étienne.--
E Ultreïa !-
[^]Re: Troll à gogo
Posté par Laurent J (page perso, ) le 03/04/2008 à 09:51. (lien). Évalué à 3.>Sauf qu'au final, les applis qui utilisent Gecko sont écrite en XUL.
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 (page perso, ) le 04/04/2008 à 12:59. (lien). Évalué à 2.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.
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
Il suffit de tester le nouveau firefox 3 pour comprendre qu'epiphany n'avait plus lieu d'etre .... integration parfaite au niveau widgets , gnomeprint, cairo, patch ubuntu pour notification-daemon ...
-
[^]Re: Firefox 3
Posté par Camille_B (Jabber id, page perso, ) le 02/04/2008 à 13:15. (lien). Évalué à 4.Non, là je ne suis pas d'accord. Firefox 3 est bien mieux intégré à Gnome, c'est certains. Mais Epiphany garde tout son intérêt. Il reste beaucoup plus sobre, son système de gestion de signets (bien que Firefox s'en approche de plus en plus) reste un brin plus efficace et simple.
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 (Jabber id, page perso, ) le 02/04/2008 à 16:18. (lien). Évalué à 2.Et reste totalement pas intégré au reste des bureaux linux... J'adore quand ils disent "intégration linux" et que tu te paye le sélecteur de fichier horrible de GNOME alors que t'es dans KDE ou WindowMaker... Enfin s'ils ont réglé la consommation de RAM et les plantages à répétition c'est pas si mal...
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.).
-
[^]Re: Firefox 3
Posté par Étienne Bersac (Jabber id, page perso, ) le 02/04/2008 à 17:03. (lien). Évalué à 4.Ave,
Quand XUL rendra exactement chaque widget en Gtk+ (comme du Glade), alors on pourrait peut-être éventuellement dire ça. Essaie simplement de passer d'un onglet à l'autre avec la molette. On est loin du compte.
Étienne.--
E Ultreïa !
Donc, en comptant les points...
WebKit semble de plus en plus en position de force pour le futur:
- 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 (Jabber id, page perso, ) le 03/04/2008 à 09:13. (lien). Évalué à 4.On peut penser aussi que vu que Google et Apple veulent utiliser WebKit pour de l'embarqué (respectivement dans Android et iPhone, comme tu l'indiques), ils vont vouloir améliorer le moteur et colmater le maximum de leaks/.
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 Fanboy Scout () le 03/04/2008 à 14:30. (lien). Évalué à 2.Un autre tres gros utilisateur de Webkit , c'est Adobe avec sa plateforme AIR/Apollo
-
[^]Re: Donc, en comptant les points...
-
-
[^]Re: Donc, en comptant les points...
Posté par Erwan (page perso, ) le 04/04/2008 à 20:19. (lien). Évalué à 4.C'est pas sur... l'iPhone OK, mais:
* 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.
Cette page a été générée par Templeet en 0.4142s (dont 0.13 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.