Développeur : KDE doit-il abandonner KHTML pour Webcore ?
Posté par Beretta_Vexee (). Modéré le 13 mai 2005.
L'affaire fait suite au passage de l'Acid2 Standards-Compliant Test (test de compatibilité avec les standard Web extrêmement exigeant) par Safari.
![[en]](../images/en.png)
Apple WebCore (1028 hits)-
Le Blog de David Hyatt (programmeur principal de WebCore) (987 hits)
-
Zack Rusin's blog (KDE) (673 hits)
-
La nouvelle sur Cnet (354 hits)
-
La nouvelle sur /. (503 hits)
-
Un article annonciateur sur /. (338 hits)
> Lire la dépêche (110 commentaires, moyenne: 3,6).
Vous avez demandé le commentaire #574094.
Run by 
Cette page a été générée par Templeet en 0.0543s (dont 0.0074 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Démagogie
Cette proposition d'Apple n'est rien d'autre que de la démagogie : "Abandonnez votre joujou puisque vous manquez de ressources pour le faire évoluer vous-mêmes, et prenez le nôtre, on vous l'offre. Laissez tomber cette base de code que vous connaissez bien, que vous maîtrisez, et prenez celui de WebCore, qui n'y ressemble plus du tout..." Ah oui, le portage de WebCore ne risque pas de se faire en deux coups de baguette magique, mais Apple pourra dire que ce sont les dév KDE qui y mettent de la mauvaise volonté, et tout le monde risque de les croire, tellement Apple avait réussi à faire croire que leur boulot sur WebCore allait rapidement faire progresser KHTML.
Vu sur le blog d'un dév KHTML il y a peu : http://www.kdedevelopers.org/node/view/1006(...)
In December 2004 I “ported” the CSS text-shadow property from WebCore. I put ported in quotes because the only thing ported was the code to parse the property. In the rendering Apple had created an extension to KWQ (their Qt) that used an OS X call to draw the shadow. This meant that to “port” it I had to write the shadow drawing myself.
Résumé : pour certaines fonctionnalités, WebCore utilise les bibliothèques d'OSX, qui sont loin d'être libres. Porter WebCore nécessiterait donc de réécrire énormément de fonctionnalités fournies par ces biblio. Faire cette proposition alors qu'Apple sait que KHTML n'a actuellement que de faibles resources me fait vraiment penser à un gros foutage de gueule...
[^]Re: Démagogie
Il n'y a rien de vraiment choquant dans le comportement d'Apple. Le seul truc, c'est une mésentente à la base sur l'avenir du projet. D'un fork amical, c'est devenu un fork inamical, mais bon, ça s'arrête là.
De toutes manières, si l'équipe de KHTML ne veulent pas reprendre le code qu'on leur propose, c'est qu'ils estiment qu'il est moche. Par conséquent, WebCore va être un soft buggé, difficile à faire évoluer. Pas de quoi piquer une crise.
C'est juste dommage pour les dev de KHTML qui ont perdu du temps dans cette "pseudo collaboration" ; maintenant, KHTML ne va pas bénéficier deu développement d'Apple, et vice versa. La communauté des gens capables de faire des rapports de bugs corrects et de proposer des patches est du côté de KHTML, donc WebCore va y perdre au moins autant que ce qu'ils avaient gagné. C'est une histoire de stratégie d'entreprise.
Si par contre ce comportement est juste dû à quelques kékés qui n'ont rien compris au libre et qui plombent la stratégie d'Apple par flemme ou pour se faire mousser, ça va chauffer. Mais je ne crois pas qu'il s'agisse de ça.
[^]Re: Démagogie
Le problème c'est que Apple n'a jamais dit avoir fait un fork et son moteur s'identifie toujours comme KHTML en utilisant les propriétés CSS -khtml-....
Ceci fait que de nombreuses personnes s'imaginent que Konqueror et Safari ont le même rendu et donc quand un truc marche sur Safari mais pas Konqueror les bugs-reports ressemblent à "TrucMuche work on Safari but not on Konqueror. How is it possible ? Please fix this quickly".
Je comprend que ça fasse raler les développeurs KHTML car l'inverse est plus rare, les utilisateurs Konqueror étant plus au courant du fait que WebCore est un fork et non le même projet comme Apple semble le faire croire.
Webcore est un fork sauvage de KHTML. Que les développeurs web le sachent et arrêtent de faire chier l'équipe KHTML avec Safari qui lave plus blanc. Apple a des moyens et l'équipe KHTML est restreinte et a peu de moyen. Les développeurs de KHTML étant en plus souvent développeurs sur d'autres parties de KDE.
[+] [^]Re: Démagogie
> les bugs-reports ressemblent à "TrucMuche work on Safari but not
> on Konqueror. How is it possible ? Please fix this quickly".
kde n'a qu'à faire comme les autres ânes de la mozilla fondation et déposer la marque khtml, il parait que ça aide à ne plus avoir ce genre de bugreport
[:kiki]
[+] [^]Re: Démagogie
En lisant ce post, je me demande si c'est pas plutôt :
Utilisez WebCore plutot que KHTML pour que vous nous débuggiez gratis le code pourri qu'on a pondu.
man man, man !
[^]Re: Démagogie
Apple a intérêt à ce que les développeurs de KDE utilisent Webcore, comme ca Webcore continuera d'évoluer grâce a la communanuté. Ils ont pas compris qu'on peut pas dicter à la communauté du libre de suivre ses choix commerciaux.