Je reprends ce que j'ai dit sur la mailing-list "pompeur" :
Il est bien sympa Ben en critiquant l'équipe de KDE, en disant que Safari est
largement meilleur que Konqueror et en disant que Apple a respecté la licence
donc qu'ils n'ont rien à dire.
Si j'ai bien suivi les dernières nouvelles, la Fondation Mozilla a posé des
restrictions sur l'utilisation des mots Firefox et Mozilla. Or Apple utilise
toujours "khtml" pour son fork de KHTML ce qui a entraîné et entraîne
toujours des problèmes.
Premièrement, quand Apple a annoncé sa sortie de Safari en disant qu'il était
basé sur KHTML il n'a pas suffisament précisé qu'il avait fait un fork de
KHTML. Donc beaucoup de développeurs et de site-webs on considéré que tester
un site sur Safari suffisait et que ça roulerait pour Konqueror. Des sites
qui avaient fait des comparatifs des propriétés reconnues par les différents
navigateurs ont complétement fait disparaitre toute allusion à Konqueror en
précisant de se référer à Safari. Bref Konqueror n'existait pas beaucoup mais
la pub d'Apple pour son "Safari basé sur KHTML" a tué toutes références à
Konqueror. Même Tristan ne le cite jamais sur son Standblog :)
Ca a aussi entrainé de nombreux mécontentements d'utilisateurs ou
développeurs-webs venu raler auprès de l'équipe KDE (via mail, bugzilla,...)
pour dire "Ca marche avec Safari, qu'est ce que vous foutez ? Alos vous
appliquer le patch quand ?". Ils pensent que Apple fournit des patchs à
l'équipe KDE ce qui n'est pas le cas. A chaque version de Safari tout le
source est mis à disposition. Les développeurs KDE doivent se taper le source
pour voir ce qu'il y a de nouveaux. Et quand ils y arrivent ils tombent sur
de l'Objective C, l'utilisation de couches native de Mac OS X.,.... ce qui
est normal mais ça n'aide pas l'application des patchs que les utilisateurs
attendent en ralant.
Apple a accès au modification du code de KHTML et aux mailing-list de KDE.
L'équipe de KDE a accès à des tarballs dès qu'une version de Safari est
disponible.
L'équipe KDE a le droits aux gens qui ralent parce qu'ils veulent la même
chose que Safari.
Apple n'a aucune plainte d'utilisateurs leur demandant d'implémenter les
choses que Konqueror a mais pas Safari (il y en a peu mais il y en a).
Bref la coopération ne va que dans un sens.
Qui plus est, Webcore s'identifie comme KHTML et les propriétés CSS
spécifiques à Webcore commencent par -khtml-... ce qui fout la grouille.
Apple aurait dû forker intégralement en utilisant -webcore-...
Et je rajoute suite à "Que les développeurs de KDE devrait être moins exigent, corriger plus de bugs plus vite et sortir leurs produits dans les temps" :
L'équipe qui travaille sur KHTML travaille aussi sur les librairies KDE et sur Koffice. Contrairement à l'équipe Mozilla ou Safari, ils ne développent pas uniquement pour le navigateur et son en effectif beaucoup plus réduit. Et malgré ça Konqueror avance à grand pas. Ils ont déjà intégré les modifs pour passer une partie du test Acid2 ; Konqui 3.4 supporte la propriété text-shadow et les compteurs CSS ; il supporte aussi le SVG animé. Et pour tout ça Mozilla ne le fait pas encore.
Ben n'a pas totalement tord mais je le trouve insultant vis à vis de l'équipe KDE.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Santa Barbara
Posté par Infernal Quack (site web personnel) . En réponse à la dépêche KDE doit-il abandonner KHTML pour Webcore ?. Évalué à 10.
Il est bien sympa Ben en critiquant l'équipe de KDE, en disant que Safari est
largement meilleur que Konqueror et en disant que Apple a respecté la licence
donc qu'ils n'ont rien à dire.
Si j'ai bien suivi les dernières nouvelles, la Fondation Mozilla a posé des
restrictions sur l'utilisation des mots Firefox et Mozilla. Or Apple utilise
toujours "khtml" pour son fork de KHTML ce qui a entraîné et entraîne
toujours des problèmes.
Premièrement, quand Apple a annoncé sa sortie de Safari en disant qu'il était
basé sur KHTML il n'a pas suffisament précisé qu'il avait fait un fork de
KHTML. Donc beaucoup de développeurs et de site-webs on considéré que tester
un site sur Safari suffisait et que ça roulerait pour Konqueror. Des sites
qui avaient fait des comparatifs des propriétés reconnues par les différents
navigateurs ont complétement fait disparaitre toute allusion à Konqueror en
précisant de se référer à Safari. Bref Konqueror n'existait pas beaucoup mais
la pub d'Apple pour son "Safari basé sur KHTML" a tué toutes références à
Konqueror. Même Tristan ne le cite jamais sur son Standblog :)
Ca a aussi entrainé de nombreux mécontentements d'utilisateurs ou
développeurs-webs venu raler auprès de l'équipe KDE (via mail, bugzilla,...)
pour dire "Ca marche avec Safari, qu'est ce que vous foutez ? Alos vous
appliquer le patch quand ?". Ils pensent que Apple fournit des patchs à
l'équipe KDE ce qui n'est pas le cas. A chaque version de Safari tout le
source est mis à disposition. Les développeurs KDE doivent se taper le source
pour voir ce qu'il y a de nouveaux. Et quand ils y arrivent ils tombent sur
de l'Objective C, l'utilisation de couches native de Mac OS X.,.... ce qui
est normal mais ça n'aide pas l'application des patchs que les utilisateurs
attendent en ralant.
Apple a accès au modification du code de KHTML et aux mailing-list de KDE.
L'équipe de KDE a accès à des tarballs dès qu'une version de Safari est
disponible.
L'équipe KDE a le droits aux gens qui ralent parce qu'ils veulent la même
chose que Safari.
Apple n'a aucune plainte d'utilisateurs leur demandant d'implémenter les
choses que Konqueror a mais pas Safari (il y en a peu mais il y en a).
Bref la coopération ne va que dans un sens.
Qui plus est, Webcore s'identifie comme KHTML et les propriétés CSS
spécifiques à Webcore commencent par -khtml-... ce qui fout la grouille.
Apple aurait dû forker intégralement en utilisant -webcore-...
Et je rajoute suite à "Que les développeurs de KDE devrait être moins exigent, corriger plus de bugs plus vite et sortir leurs produits dans les temps" :
L'équipe qui travaille sur KHTML travaille aussi sur les librairies KDE et sur Koffice. Contrairement à l'équipe Mozilla ou Safari, ils ne développent pas uniquement pour le navigateur et son en effectif beaucoup plus réduit. Et malgré ça Konqueror avance à grand pas. Ils ont déjà intégré les modifs pour passer une partie du test Acid2 ; Konqui 3.4 supporte la propriété text-shadow et les compteurs CSS ; il supporte aussi le SVG animé. Et pour tout ça Mozilla ne le fait pas encore.
Ben n'a pas totalement tord mais je le trouve insultant vis à vis de l'équipe KDE.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire