WebKit dans KDE

Posté par  (site web personnel) . Modéré par Nÿco.
Étiquettes : aucune
0
25
juil.
2007
Apple
Pour mémoire, KHTML est le moteur de rendu HTML développé par KDE et KJS est l'interpréteur Javascript, le tout étant donc intégré à Konqueror, le navigateur web et gestionnaire de fichiers.

Apple a démarré un fork de KHTML/KJS en 2002 et a nommé ce projet WebKit (WebCore pour le moteur HTML, JavaScriptCore pour l'interpréteur Javascript), et l'a intégré à son navigateur Safari.

Les relations entre Apple et KDE n'ont pas toujours été très bonnes, Apple n'étant pas très coopératif (patchs difficiles à importer dans KHTML, livraison par lot, etc.), les choses se sont finalement arrangées, Apple ayant ouvert le développement de WebKit aux contributions externes.

Quelques autres forks plus ou moins mineurs de KHTML/KJS et de Webkit sont également apparus.

Suite à cela, Trolltech a commencé à s'intéresser au projet et travaille en ce moment à l'intégration de WebKit dans la version 4.4 de l'environnement Qt.

Finalement durant l'Akademy 2007 à Glasgow, il fut décidé que WebKit sera le moteur HTML de Konqueror à l'avenir et que KHTML allait disparaître. Entre temps, les améliorations CSS3 implémentées dans KHTML uniquement seront portées dans WebKit.

La boucle est donc bouclée !

Aller plus loin

  • # Normalisation et innovation

    Posté par  (site web personnel) . Évalué à 10.

    Cette nouvelle est une nouvelle comme on voudrait en voir souvent. Elle est à rapprocher de Fusion qui est la réunification de Beryl et de Compiz lui-même issu d'un fork de Compiz.

    Il s'agit là d'une grande force des logiciels libres. L'innovation est toujours présente et lorsque toutes les voies ont été explorées, la meilleure solution se dégage sur des critères techniques avérés. Elle devient alors une sorte de norme par dessus laquelle un nouveau cycle d'innovations peut alors apparaître.
    Ce mécanisme est infiniment plus fiable que les décisions d'un directeur commercial et donne des résultats bien plus pérennes.

    Jusqu'à présent Apple de contentait de prendre (licence BSD) et donnait peu.
    Espérons que la politique d'Apple s'oriente vers plus de réciprocité, ce qui est le vrai sens des logiciels libres. Il s'agit d'un premier pas, réjouissons-nous !

  • # Petites questions toutes simples...

    Posté par  . Évalué à 6.

    * Qu'entend-on par "livraison par lot" ? C'est un reproche fait à Apple dans cette news, mais je ne vois pas de quoi il s'agit...
    * De plus, pourquoi avoir choisi de basculer vers WebKit, plutôt que de garder KHTML? Le premier aurait-t-il donc beaucoup plus évolué que le second?
    * Enfin, l'intégration de WebKit dans Qt 4.4 ne rendra-t-il pas ce moteur de rendu trop dépendant de l'univers Qt? Car si cela peut être intéressant pour l'intégration à KDE, cela l'est sans doute moins pour Apple (et les autres projets l'utilisant? Je n'en connais pas mais ce n'est pas une raison...)

    • [^] # Re: Petites questions toutes simples...

      Posté par  . Évalué à 2.

      Pour le dernier point, je pense qu'il faudrait plutôt comprendre ça comme : "Trolltech va rendre accessible WebKit dans Qt4.4", et non pas "WebKit va être intégré à Qt4.4".

      Donc au final, les développeurs Qt auront la possiblité d'utiliser un composant "natif" (qui utilisera lui, WebKit).

      On trouve un peu le même genre de projet pour Gtk (http://gtk-webcore.sourceforge.net/), même si ça a pas l'air de trop bouger.

    • [^] # Re: Petites questions toutes simples...

      Posté par  (site web personnel) . Évalué à 8.

      * De plus, pourquoi avoir choisi de basculer vers WebKit, plutôt que de garder KHTML? Le premier aurait-t-il donc beaucoup plus évolué que le second?

      Plusieurs pistes :
      peut être un petit peu le fait que WebKit "sonne plus indépendant" que KHTML,
      que depuis qu'Apple a mis un vrai site communautaire autour du projet avec Bugzilla, Nighty builds binaires, ça bouge bien,
      et surtout je pense : de grosses boîtes ont indiqué leur support du projet : Nokia, Adobe, Trolltech, etc.

    • [^] # Re: Petites questions toutes simples...

      Posté par  . Évalué à 10.

      >* Qu'entend-on par "livraison par lot" ? C'est un reproche fait à Apple dans cette news, mais je ne vois pas de quoi il s'agit...

      Et bien c'est facile, quand des développeurs fournissent des patches a Linux, il les découpent en petit morceaux 'autonome' (et ce n'est pas une mince affaire) qui rendent la relecture et l'intégration des patch simple.

      Apple a forké comme un gros sagouin KHTML, rendant les modifications du code disponible (comme la licence l'impose) mais sans découpage, donc quand il fournissait une nouvelle version, le diff entre Webkit et KHTML est une bouse énorme, pas utilisable.

      Apparemment il va y avoir fusion des deux donc on peut espérer un projet qui avance plus vite en final, mais bon Apple a quand même bien embêté le monde avec son fork sauvage..

      Pour le deuxième point, coopérer avec une boite de la taille d'Apple, ça a quand même des avantages évidents..

      Pour le troisième point, vu que WebKit est portable sur MacOS X, Windows, GTK et Qt, je ne vois pas comment WebKit pourrait être rendu 'trop dépendant' de Qt, tu crois qu'Apple laisserait faire ça??

      • [^] # Re: Petites questions toutes simples...

        Posté par  . Évalué à 1.

        Merci pour toutes ces précisions...

        Et non, je n'imagine pas Apple laisser WebKit devenir trop dépendant d'une techno qu'ils ne contrôlent pas!

    • [^] # Re: Petites questions toutes simples...

      Posté par  (site web personnel) . Évalué à 9.

      D'après les diverses sources qui parlent de cet événement, l'historique (et les raisons des choix décidé maintenant) sont les suivants:
      *au début, il y avait khtml, dépendant fortement de KDE;
      *lorsque Apple a décidé de baser Safari sur Khtml, ils ont du enlever cette dépendance à KDE en généralisant Khtml
      *ce fork indépendant de KDE s'est appelé WebKit
      *au fils du temps, plein d'autres intervenants se sont intéressés à WebKit, des forks de WebKit ont vu le jour (pour l'embarqué, pour utiliser un front end gtk, ...)
      *aujourd'hui, KDE choisirait de synchroniser WebKit et Khtml puis d'utiliser WebKit uniquement

      Donc d'après ce que je comprend, on va vers un WebKit indépendant du toolkit (qt, gtk, quartz...) qui soit proprement utilisable par plein d'intervenants dans des situations tres diverses (Nokia pour ses téléphones, Apple pour Safari, KDE pour Konqueror, Trolltech pour le rendu html dans QT, Gnome pour Epiphany, et d'autres...).

      Mathias

  • # Annonce prématurée

    Posté par  . Évalué à 5.

    Je répète ce que j'ai écrit dans le journal ad-hoc :
    A la lecture des commentaires sur le dot (dot.kde.org), il n'apparaît pas évident du tout que WebKit va remplacer KHTML.

    Pour l'instant, il s'agit juste de créer un KPart qui puisse remplacer KHTML dans Konqueror, mais les développeurs de KHTML n'ont pas l'air unanime sur la décision (ou non) de faire de WebKit le moteur principal et/ou unique.

    A suivre donc.

    Je me réfère surtout au commentaire de SadEagle sur le dot, et à une lecture attentive de l'article.

    • [^] # Re: Annonce prématurée

      Posté par  (site web personnel) . Évalué à 1.

      En effet, pour l'instant, et d'apres les discutions de l'akademy, c'est un KPart webkit qui puisse remplacer KHTML dans Konqueror. Pour le reste, c'est à dire l'avenir, c'est plutot flou d'apres les différentes discutions que j'ai eu (n'ayant pu assister à la conférence).

      Cela dis, la conférence est disponible ici:
      http://conference2007.kde.org/conference/programme.php

      • [^] # Re: Annonce prématurée

        Posté par  . Évalué à 5.

        Oui pour l'instant, j'ai l'impression que Maksim Orlovich et Germain Garand (deux développeurs de KHTML) ne souhaitent pas passer à Webkit à cause de la lourdeur de la procédure de commit mise en place par Apple et du fait que Apple, Trolltech et d'autres sponsorisent certains développeurs de Webkit provenant de la communauté KDE et que ceux qui ne sont pas sponsorisés sont un peu marris.

        C'est évidemment dommage mais ce sont des frictions inévitables dans des situations de co-développement entre bénévoles et développeurs salariés.

  • # Archiver une page

    Posté par  . Évalué à 4.

    Tant qu'on parle de Konqueror, je me demandais (jusqu'il y a quelques minutes) s'il était possible d'enregistrer des pages HTML en MHTML (HTML encapsulé, *.MHT). M'attendant à un Google is your friend, j'ai fait ma petite recherche. J'ai découvert le format KDE Web Archive (*.WAR). Il devrait être possible de convertir les MHTML en WAR avec kmhtconvert mais ça n'a pas marché chez moi (avec la version 0.7.3-0ubuntu2).

    Je trouve ça tout de même étrange et peu intuitif que dans Konqueror il faille faire "Outils -> Archiver la page Web" au lieu de "Document -> Enregistrer sous..." puis choisir le format voulu (comme c'est le cas dans Opera, et aussi IE je crois).

    • [^] # Re: Archiver une page

      Posté par  . Évalué à 4.

      'Enregistrer sous' permet habituellement d'enregistrer la page web sans ses dépendances, donc uniquement le code chargé par le navigateur.

      'Archiver la page web' est un petit plus, il enregistrer la page et ses dépendances (images, sous-dossiers, fichiers multimédia,...) et comprime tout ça dans un fichier *.war. Ce fichier est reconnu par Konqueror comme une 'archive web' et est consultable off-line.

      Un fichier *.war est tout simplement une archive compressée par Gzip contenant tout les fichiers dont la page web dépend.
      Cet outil n'est pas proposé par tous les navigateurs, pour Firefox, c'est un addons.

      • [^] # Re: Archiver une page

        Posté par  . Évalué à 8.

        Ouais, enfin pour quelqu'un qui ne sait pas (et se fout de savoir) comment fonctionne une page web, le système enregistrer la page de konqueror n'est pas intuitif du tout.
        En effet, pourquoi est-ce que les images ne feraient pas partie de la page web?

        Dans ce contexte, je trouve qu'un comportement correct serait de proposer, lors de l'enregistrement d'une page web:
        * enregistrer la page sans les images (*.html)
        * enregistrer la page complète (*.war)

        Ma copine par exemple, lorsqu'elle veut enregistrer une page web, elle utilise firefox, parce que "avec konqueror ça marche pas".

    • [^] # Re: Archiver une page

      Posté par  . Évalué à 1.

      Concernant la conversion MHT -> WAR, j'ai effectué le test suivant: j'ai enregistré une page web en MHT avec Opera ensuite je l'ai lue avec Opera pour la réenregistrer en HTML avec images. Eh bien, Opera n'enregistre cette fois que le fichier HTML, il n'enregistre pas les images en les mettant dans un dossier à côté alors que je le lui ai demandé. J'ai effectué le test plusieurs fois, il refuse de conserver les images. En plus, il y a 5 à 6 lignes de code qui appaissent au début de la page HTML. Quant au bas de la page, on a droit à une multitude de lettres et de chiffres, et ce sur des dizaines de lignes. Conclusion: Opera lui-même ne parvient pas à réencoder proprement ses MHT en pages HTML normales !



      J'ai constaté un autre problème d'ergonomie dans Konqueror:
      Faire "Configuration -> Configurer Konqueror... -> Identification par site" ne permet pas de choisir de faire identifier par défaut le navigateur comme étant autre chose que Konqueror (on peut choisir pour un site spécifique mais pas pour tous). Pour le faire identifier comme étant Opera, InternetExplorer,... pour tous les sites il faut faire "Outils -> Modifier l'identité du navigateur". Ce serait bien que l'identification comme étant un navigateur autre que Konqueror (Opera, InternetExplorer,...) puisse se faire depuis "Configuration -> Configurer Konqueror... -> Identification par site". Mais bon, passons, on verra bien dans la version 4.0...



      Enfin, je me demande pourquoi l'ULg force les internautes à utiliser (ou à tout le moins à se faire passer pour) Mozilla, Firefox et Netscape (Quoi ? Netscape est encore vivant ?) pour accéder à certaines parties de son site. Avec Opera, ça ne marche qu'en se faisant passer que pour Firefox. Quand je veux me faire passer pour InternetExplorer ou Opera, le site me dit "Votre navigateur n'est pas adapté à la consultation de ce site...". Quant à Konqueror, il se fait lui aussi refouler à l'entrée. Konqueror a un peu plus de chance qu'Opera quand il se fait passer pour InternetExplorer. Mais le plus intéressant (selon moi), c'est que Konqueror n'est pas rejeté quand il se fait passer pour Safari (2.0 ou 1.2.4) !

      La page incriminée:
      http://welcome.ulg.ac.be/erasmusout/destinations.jsp

      Une autre façon de procéder est d'aller sur http://www.ulg.ac.be/aeerni/socrates/erasmus-out/
      puis de cliquer sur "liste des destinations"

      Maintenant, je me demande comment parler de ce "problème" au webmestre sans obtenir comme réponse "Vous n'avez qu'à utiliser Firefox ou InternetExplorer comme tout le monde !"...

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.