0
WebKit est un moteur de rendu HTML open-source (certaines portions sont en LGPLv2, d'autres en licence BSD). WebKit est aussi le nom de la version framework disponible sur les systèmes Mac OS X et utilisé par le navigateur Safari, DashBoard, Mail et plein d'autres applications Mac OS X. Le projet est une branche de KHTML et des bibliothèques KJS venant de KDE.
Ce projet a édité un ensemble de règles régissant les contributions extérieures. Historiquement, l'acceptation des contributions était régenté par un processus interne à Apple.
Les nouvelles directives principales sont :
- Les nouveaux contributeurs et relecteurs seront choisis parmi les contributeurs actuels ;
- Le nouveau processus traite tout le monde à égalité, quelle que soit l'entreprise d'affiliation ;
- Les règles pour être considéré comme un potentiel contributeur sont claires et connues.
![[en]](../images/en.png)
L'annonce (252 hits)-
La charte (149 hits)
-
Réaction par Liquidat (254 hits)
> Lire la dépêche (47 commentaires, moyenne: 4,3).
Vous avez demandé le commentaire #889073.
Run by 
Cette page a été générée par Templeet en 0.0537s (dont 0.0059 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
La réponse de Zack Rusin à la "KHTML Future FAQ"
La réponse de Zack Rusin, développeur important de Qt (ex employé de Trolltech) au blog d'Harri Porten est à la fois cinglante et rigolote :
http://zrusin.blogspot.com/2007/10/khtml-future.html
Son argument final m'a convaincu : un intérêt majeur de converger autour d'un seul moteur, si possible le moteur utilisé par Apple/Safari, c'est que ce moteur sera testé et supporté par les webdesigners, surtout pour les gros sites (gmail, google documents, etc.). Un KHTML divergent de Webkit et utilisé par 1% des surfeurs, fut-il techniquement meilleur (et c'est improbable), sera de toutes façons moins supporté par les sites web que le moteur intégré dans Safari. Or pouvoir afficher correctement les sites webs (même les sites passablement défectueux) est quand même le but premier d'un navigateur.
[^]Re: La réponse de Zack Rusin à la "KHTML Future FAQ"
Fondamentalement, je pense qu'il a raison et qu'une fois que WebKit sera intégré à Qt, il y a peu de chance qu'un autre moteur soit utilisé dans KDE.
Maintenant, WebKit ne sera dans Qt que dans la 4.4, sur laquelle KDE ne s'appuyera apparemment pas avant un long moment. Autrement dit, il y a de bonnes chances que KHTML soit le moteur de KDE pendant un ou deux ans encore. Aussi, dénigrer les devs qui continuent de travailler dessus ne me parait pas de la plus grande finesse : on devrait au contraire leur savoir gré de continuer à maintenir un moteur qui a de bonnes chances d'être abandonné.
Par ailleurs, c'est peut-être aussi leur intransigeance qui a poussé Apple à ouvrir un peu plus sa manière de fonctionner, ce que n'aurait peut-être fait la souplesse des messieurs Rusin et co.
Autrement dit, cette réponse de Mr Rusin me parait aussi l'expression d'un égo, et j'espère surtout que ces gens vont parvenir à s'entendre au final, car ils ont tous beaucoup de mérite.
En note final, si l'argument qu'une solution doit être choisie sous prétexte qu'elle est plus répandu est si recevable que cela, il n'y aurait pas de logiciels libres, nous utiliserions tous MS.
[^]Re: La réponse de Zack Rusin à la "KHTML Future FAQ"
Je peux me tromper, mais je pense que Webkit n'a pas besoin d'être inclus dans QT pour être le moteur de rendu HTML de Konqueror.
[^]Re: La réponse de Zack Rusin à la "KHTML Future FAQ"
Non, tu ne te trompes pas. Seulement, il faut un coder un kpart, qui apparemment n'existe pas encore (ou alors est incomplet), et par ailleurs, cela ajoute une dépendance forte pour KDE avec une librairie qui n'est, il me semble pour le moment, pas fournie par défaut par les distributions (et pour cause, personne ne l'utilise sous Linux). C'est donc un gros effort que personne, même les gens intéressés en Webkit, ne veut vraiment faire, et pour cause.
Une fois intégrée à Qt, Webkit sera distribué plus largement et systématiquement, et la tentation sera du coup beaucoup plus grande de l'utiliser. Il est à parier que des gens comme Mr Rusin prendront alors le temps de faire un kpart complet.
[^]Re: La réponse de Zack Rusin à la "KHTML Future FAQ"
Si, si, comme dit dans la news, le kpart existe et compile http://blog.gwright.org.uk/articles/2007/11/23/webkit-kde
en fait, le kpart a été mis de coté depuis un moment, mais depuis l'intégration de webkit dans KDE [http://websvn.kde.org/trunk/playground/libs/webkitkde/] le kpart est de nouveau travaillé.
AMHA, les jours de khtml sont comptés.
http://linuxfr.org/board <-- des moules, du sang, de la violence
[^]Re: La réponse de Zack Rusin à la "KHTML Future FAQ"
Intéressant. Ils ont l'air de parler de KDE 4.1, même si rien ne dit que KDE 4.1 utilisera Qt 4.4.
Enfin bon, on verra bien.
J'espère juste que les devs de KHTML ne seront pas dégoutés au point d'abandonner purement et simplement le support de HTML dans KDE. C'est en cela que je trouve la réaction de Rusin pas très maline. Je pense que l'attitude des gens d'Apple, qui cherche plutôt à tenter de se rapprocher de ces devs, est plus constructive.