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.
[^] # Re: Bonne décision
Posté par Julien . En réponse à la dépêche Epiphany va migrer vers du 100% WebKit. É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.