Discussion :

[dourouc05]

Nokia annonce les prochaines versions de QtWebKit
QtWebKit 2.1 apportera le support de HTML5 sur Symbian et MeeGo

Mise à jour du 08/03/2011 par dourouc05


Après avoir été projet pionnier de la modularisation de Qt, qui devrait arriver pour Qt 4.8, QtWebKit fait enfin à nouveau entendre parler de lui, en annonçant les prochaines versions.

QtWebKit 2.1 se focalisera sur le support des plateformes Nokia (c'est-à-dire Symbian et MeeGo), toujours en se basant sur Qt 4.7. Il corrigera un certain nombre de bogues et apportera le support d'un certain nombre d'éléments de HTML5.

QtWebKit 2.2 sera, quant à lui, dirigé vers Qt 4.8, toutes plateformes confondues. Il se basera sur un nouvel export du tronc de WebKit, la révision est toujours à décider.

En préparation pour ces nouveautés, le support de Qt 4.6 sera bientôt enlevé du tronc de QtWebKit.

Source



QtWebKit commence à se découpler de Qt dès la version 2.0

La version 2.0 de QtWebKit, attendue pour mai 2010, sera la première version à être distribuée en dehors de Qt : le module continuera à être inclus dans les distributions de Qt, avec toutes ses dépendances, avec un support commercial pour ceux qui l'ont acheté, mais les releases du modules seront désynchronisées par rapport à celles de Qt. Cette version 2.0 sera compatible avec Qt 4.6 et 4.7.

Au final, cela ne changera pas grand chose pour l'utilisateur : rien, en fait, sauf s'il veut se maintenir à jour pour ce module, auquel cas une nouvelle version de Qt n'apportera pas forcément une nouvelle version de QtWebKit, mais le module QtWebKit pourra continuer à évoluer à son propre rythme en dehors de Qt.

En même temps, l'équipe de QtWebKit cherche des moyens pour accélérer le moteur, vu que ses utilisations ont changé : avant, WebKit était presque exclusivement utilisé sur PC ; de nos jours, il est aussi utilisé sur des périphériques mobiles, des téléphones... sous Maemo, Symbian, Windows CE ou bien d'autres.

Source : les Qt Labs.

Et vous ?

Utilisez-vous QtWebKit dans vos applications ? Ce découplage vous semble-t-il une bonne idée, ou bien auriez-vous préféré que le système actuel reste en place ?

Cette nouvelle planification des sorties permettra-t-elle de mieux suivre l'évolution de WebKit, les nouveaux besoins des utilisateurs ?

[Hayaxx]

Cette désynchronisation me paraît être une bonne chose.

Comme ça a été dit, aucun changement pour ceux qui se mettent a jour à chaque changement de version majeur de Qt.

Mais si QtWebkit est en évolution constante, et sûrement plus rapide que l'ensemble de la bibliothèque, cela ne peut que faire bouger un peu plus les développeurs, et les dernières applications disposeront de la plus fraîche des versions.

Ce serait peut-être plus complexe à gérer, mais pourquoi pas étendre ce principe à d'autres gros modules ?

[rambc]

Pour ma part, je vais utiliser le WebKit non pas pour naviguer sur le net mais pour afficher des graphiques manipulables à la souris, puis pour récupérer les données. Tout se fera via la communication entre Qt et di JavaScript.

Que les modules importants aient leur propre rythme de développement, pourquoi pas. Maintenant en pratique, faire les mises à jour séparées, il n'est pas certain que chacun le fera.

[Gulish]

En soi, ce n'est pas forcément une mauvaise chose, et ça pourra sans doute dynamiser l'évolution de QtWebKit (sans attendre une MAJ complète du framework).

Par contre, ce qui me fait peur, c'est, comme tu l'a dis :

les releases du modules seront désynchronisées par rapport à celles de Qt

Ce qui implique des risques de perdre cette "compatibilité" parfaite entre tous les modules de Qt et leurs objets. A terme, on peut se retrouver avec des modèles de données différents, et on utilisera des "passerelles" (ex. Qt 3 support library) pour faire marcher tout ça ensemble, et les performances risquent d'en prendre un coup.

Donc pour moi, séparer, pourquoi pas, mais attention à ne pas perdre ce qui fait la grande simplicité de Qt, à savoir la cohésion de tous ces modules.

G.

[Ikipou]

Par contre, ce qui me fait peur, c'est, comme tu l'a dis : Ce qui implique des risques de perdre cette "compatibilité" parfaite entre tous les modules de Qt et leurs objets. A terme, on peut se retrouver avec des modèles de données différents, et on utilisera des "passerelles" (ex. Qt 3 support library) pour faire marcher tout ça ensemble, et les performances risquent d'en prendre un coup.

Donc pour moi, séparer, pourquoi pas, mais attention à ne pas perdre ce qui fait la grande simplicité de Qt, à savoir la cohésion de tous ces modules.

Il n'y a pas de danger de ce côté-là.

L'objectif est de découpler les sorties de QtWebKit des sorties de Qt afin de mettre à jour WebKit plus souvent que Qt. A priori, 90% des utilisateurs de WebKit s'en foutent et continueront à utiliser la version livrée avec la dernière version de Qt.

Les utilisateurs les plus intéressés sont ceux qui veulent les dernières technologies de WebKit au plus tôt. Par exemple, certains voudraient le support WebGL dès maintenant, et pas attendre Qt 4.7.

Que les modules importants aient leur propre rythme de développement, pourquoi pas. Maintenant en pratique, faire les mises à jour séparés, il n'est pas certain que chacun le fera.

QtWebkit fera toujours partie du SDK, et sera mis à jour avec chaque version majeure de Qt. Donc les mises à jour séparés sont principalement utile pour ceux qui ont besoin de mettre à jour WebKit plus vite que Qt.

[lamoscawince]

ce découplage me paraît très bien.

Est-ce que la nouvelle branche qtwebkit pourra être facilement compilée pour wince? Car pour l'instant je n'ai pas encore réussi à compiler la version qtwebkit-gitorious pour wince (qt4.6.2), trop compliqué et pas documenté.

[dourouc05]

Nokia annonce les prochaines versions de QtWebKit
QtWebKit 2.1 apportera le support de HTML5 sur Symbian et MeeGo

Après avoir été projet pionnier de la modularisation de Qt, qui devrait arriver pour Qt 4.8, QtWebKit fait enfin à nouveau entendre parler de lui, en annonçant les prochaines versions.

QtWebKit 2.1 se focalisera sur le support des plateformes Nokia (c'est-à-dire Symbian et MeeGo), toujours en se basant sur Qt 4.7. Il corrigera un certain nombre de bogues et apportera le support d'un certain nombre d'éléments de HTML5.

QtWebKit 2.2 sera, quant à lui, dirigé vers Qt 4.8, toutes plateformes confondues. Il se basera sur un nouvel export du tronc de WebKit, la révision est toujours à décider.

En préparation pour ces nouveautés, le support de Qt 4.6 sera bientôt enlevé du tronc de QtWebKit.

Source : http://labs.qt.nokia.com/2011/03/03/...bkit-releases/