Discussion :

[arnolddumas]

Le web a beaucoup évolué depuis la première introduction de WebKit dans Qt en 2007. Partant de quelques pour-cent de part de marché, le projet open source est maintenant devenu un des moteurs de rendu web les plus utilisés au monde. Alors que le port Qt de WebKit était plus ou moins le premier port non commandité par Apple, beaucoup d'entreprises ont rejoint le projet pour suivre les avancées.

Le projet Chromium a joué un grand rôle dans ce projet et est devenu au fil du temps le plus gros contributeur de WebKit (suivi par Apple ainsi que Qt en troisième position). La coopération entre les différentes entreprises sur un projet open source n'a jamais été sans difficulté. C'est ainsi que Google a décidé ce printemps de quitter le projet WebKit en faveur de leur propre fork, Blink.

Depuis cela, Blink, réellement très intégré à Chromium, a pris un chemin bien différent de WebKit, les codes ont rapidement divergé. C'est pour cela que les équipes R&D de chez Digia se sont intéressées à Chromium ainsi qu'à WebKit afin de choisir lequel des deux serait à même d'offrir la meilleur expérience web au sein de Qt dans le futur.

Après des recherches quant aux meilleurs alternatives, il a été décidé d'utiliser Chromium comme futur moteur de rendu web pour Qt. Cette décision fût motivée par différentes raisons :

• Chromium se focalise sur le multiplate-forme, avec un navigateur disponible sur toutes les plates-formes majeures de bureau ainsi que sur Android. Cela n'est plus valable concernant WebKit et il faudrait que Qt supporte tous les OS spécifiquement ;
• Chromium propose énormément de chose de base, fonctionnalités qui prendraient énormément de temps à réimplémenter autour de WebKit, comme tout le travail d'adaptation aux différents systèmes d'exploitation. Le multimédia ainsi que les nouvelles fonctionnalités du HTML5 comme WebRTC fonctionnent à la sortie de la boîte et ne requièrent pas de code spécifique à Qt ;
• étant donné que l'utilisation de Chromium facilite l'intégration sur les différents systèmes d'exploitation, les équipes de développement pourront consacrer plus de temps aux tâches de plus haut niveau, comme la création d'une API facilitant son usage ainsi qu'un travail sur son intégration à Qt la plus naturelle possible ;
• Chromium est développé avec un contrôle très strict au niveau de la qualité du code. Cela simplifie les tests et réduit les efforts nécessaires à l'obtention d'un navigateur stable et de haute qualité ;
• Chromium permettra une meilleure et plus performance intégration avec à la fois les widgets et le graphe de scène de Qt Quick que n'aurait permis WebKit.

Chromium a donc été considéré comme la plate-forme la plus dynamique et active disponible. Fonder le moteur de rendu web sur Chromium est une décision stratégique à long terme. Les équipes de développement se montrent convaincues que cela permettra de proposer un moteur web pour Qt vraiment meilleur que celui se basant actuellement sur WebKit et que combiner le meilleur moteur de rendu web, notamment dans le domaine des logiciels embarqués, qui doivent combiner un moteur de rendu web avec une solution de création d'interfaces graphiques de premier choix.

Un des fondements de Chromium est que le rendu des contenus web s'effectue dans un fil d’exécution séparé pour des raisons de sécurité et de stabilité. Cela rend impossible de proposer certains aspects de l'API de Qt WebKit avec Chromium. Un élément très important est l'API QWebElement. L'incorporation des QObject devra aussi être modifiée étant donné que la communication entre les QObject et les pages web doit se passer de façon asynchrone.

Quels seront les impacts sur les utilisateurs de Qt WebKit ?

La première chose à dire : n'ayez pas peur. Pour beaucoup d'entre vous, l'intégration de contenu web avec Qt WebKit fonctionne sans souci et cela continuera dans les prochaines années. Après la sortie de Qt 5.2, les équipes de développement se concentreront sur le développement du nouveau moteur web de Qt. Ainsi, si vous voulez utiliser les nouvelles fonctionnalités excitantes de HTML5, vous devriez envisager une migration vers Qt WebEngine une fois que l'API couvrira les fonctionnalités dont vous avez besoin.

De gros efforts seront faits afin de faciliter au mieux la transition de Qt WebKit vers le nouveau Qt WebEngine. Pour l’élément WebView de Qt Quick, une API 100 % compatible sera vraisemblablement mise en place. Pour les personnes utilisant l'API de base QWebView, les nouvelles sont là aussi bonnes. La plus grande partie de l'API sera disponible dans une version compatible au niveau des sources pour le nouveau Qt WebEngine. Si vous utilisez le pont QObject ou l'API QWebElement, il est recommandé d'attendre un peu plus avant d'effectuer la transition, étant donné que l'API remplaçante ne sera probablement pas disponible pour la première sortie du nouveau Qt WebEngine.

Même si aucun futur développement ne sera effectué au niveau de Qt WebKit, la version existante sera toujours disponible et continuera de fonctionner.

Un travail important est en ce moment abattu afin de sortir une préversion technologique du nouveau Qt WebEngine aussi rapidement que possible. L'objectif est de la rendre disponible lors de la sortie de Qt 5.2 cet automne. La première version supportant totalement Qt WebEngine sera vraisemblablement Qt 5.3, prévu pour le printemps 2014. Pour la première version, il est prévu une compatibilité de Qt WebEngine avec Windows, Mac OS X, Linux ainsi que Linux embarqué.

Pour plus d'informations sur le Qt WebEngine, jetez un coup d’œil sur le wiki du Qt Project. Vous y trouverez des informations détaillées sur la façon de compiler le moteur web vous-même, sur le portage de code vers ce nouveau moteur ainsi que le plan de développement ainsi que des modules.

C'est un énorme changement pour Qt qui bénéficiera d'une plate-forme web bien plus compétitive et qualitative dans les années à venir.

Source : http://blog.qt.digia.com/blog/2013/0...-qt-webengine/

Et vous ?

Utilisez vous le module WebKit dans vos développements avec Qt ?
Que pensez vous de ce remplacement ?

[air-dex]

Utilisez vous le module WebKit dans vos développements avec Qt ?

Oui. Je l'utilise principalement pour du traitement de données HTML, notamment lors de la génération de textes riches côté C++ à afficher côté QML (où les textes riches doivent être écrits en HTML). Je suis donc plus QWebElement que QWebView.

Que pensez vous de ce remplacement ?

Ce n'est pas tellement le moteur de rendu qui est derrière qui m'intéresse le plus (même si en bon fan d'Opera je préférerai voir Presto et Carakan au lieu de WebKit/Blink et V8). C'est la manière dont Qt WebQqch est organisé qui m'intéresse.

Et personnellement cela me plait de moins en moins. Plus ça va et plus j'ai l'impression que Qt WebKit se recentre méchamment autour de l'affichage d'une page Web via une (Q)WebView, de préférence en QML. Cela se voit d'ailleurs bien avec Qt 5 où il faut désormais écrire QT += webkitwidgets au lieu de QT += webkit dans le .pro pour inclure la partie C++ de Qt WebKit dans un projet Qt. Ceci inclut forcément une QWebView et des dépendances graphiques absolument dispensables lorsque le projet ne fait pas de GUI du tout (j'ai un projet personnel comme ça). Et je ne parle même pas de la page de documentation de Qt Webkit pour Qt 5 qui ne se contente quasiment que d'afficher un exemple de WebView dans un composant QML.

Plus généralement j'ai l'impression que Qt est fâché avec le DOM. En plus de Qt WebKit je pense aussi à Qt XML où son traitement haut niveau du XML (via le DOM et les QDomElements) a été déprécié au profit d'une "QXmlStream API" bien plus bas niveau.

Pour en revenir aux Qt WebQqch j'attends surtout de Qt WebEngine qu'il résolve ces problèmes d'organisation. J'attends qu'il y ait d'un côté les "QtWebEngines" avec tout le backend (traitement de l'HTML avec la remplaçante de l'API QWebElement), et de l'autre côté les "QtWebWidgets" avec le frontend (affichage des pages Web avec la remplaçante de l'actuelle API QWebView). Libre à eux d'inclure la partie QML dans les "QtWebWidgets" ou bien de faire un 3ème module "QmlWebEngine".

Pour le reste j'attends surtout quelque chose de plus simple pour déployer Qt WebEngine en dehors du cadre de développement. Récemment j'ai essayé de déployer un projet personnel utilisant Qt WebKit (QWebElement et QWebView) et Qt 5.1 en dehors de son poste développement. J'ai lamentablement échoué à cause de Qt WebKit, en particulier sous Windows où je n'ai jamais réussi à afficher une WebView QML en dehors du poste de développement et ce malgré toutes les DLLs nécessaires incluses.

[imikado]

Que pensez vous de ce remplacement ?
Je suis étonné, le moteur de chromium n'est pas un fork de webkit ?

[Fintuiron]

Oui. Je l'utilise principalement pour du traitement de données HTML, notamment lors de la génération de textes riches côté C++ à afficher côté QML (où les textes riches doivent être écrits en HTML). Je suis donc plus QWebElement que QWebView.

Tu utilises quoi qui nécessite webkit ?
Un simple QLabel peut afficher du HTML (texte, mise en forme, lien internet, images, etc), pas besoin de webkit a priori

[dourouc05]

À vrai dire, je pense que dire que Chromium remplace WebKit est mensonger : Chromium, c'est bien plus qu'un moteur d'affichage Web (pile multimédia, pile réseau, notamment) – Chromium est prévu comme une base pour des navigateurs, comme Opera 14/15 et suivants.

Je suis étonné, le moteur de chromium n'est pas un fork de webkit ?

Si, mais avec une organisation en processus différente, avec en toile de fond une volonté d'Apple de ne plus voir Google utiliser son code (si j'ai bien tout suivi ).

[air-dex]

Tu utilises quoi qui nécessite webkit ?
Un simple QLabel peut afficher du HTML (texte, mise en forme, lien internet, images, etc), pas besoin de webkit a priori

J'ai 3 projets persos utilisant Qt WebKit :

1. Le premier n'utilise que QWebElement, QWebPage et QWebFrame. C'est une librairie qui wrappe des (REST) API Web et qui met les résultats dans des structures un peu plus haut niveau que les chaînes de caractères brutes renvoyées par les APIs. Elle propose également les quelques utilitaires qu'elle utilise pour ça (entre autres pour manipuler de l'HTML). Rien de graphique donc. Ma librairie parse de l'HTML (pour le retourner dans un QWebElement) ou bien crée une balise dont je récupère le code HTML via QWebElement::toOuterXML();. Je sais que dans le second cas je pourrais me contenter d'une QString où j'écrirais mon code HTML à grands coups de QString::append();, mais je préfère utiliser une librairie (ici l'API QWebElement) dont je sais qu'elle fera le travail mieux que moi.
2. J'ai un deuxième projet (appli PEBKAC.fr) qui utilise le premier pour créer des liens à afficher côté QML (et aussi pour interagir avec l'API de PEBKAC).
3. Enfin j'ai un troisième projet qui utilise carrément tout Qt WebKit (client Twitter où il faut afficher la page Web retournée par l'API Twitter lors de l'authentification + usages du 2ème projet mais pour Twitter et non PEBKAC).

[loupium]

Bonsoir,

J'ai lamentablement échoué à cause de Qt WebKit, en particulier sous Windows où je n'ai jamais réussi à afficher une WebView QML en dehors du poste de développement et ce malgré toutes les DLLs nécessaires incluses.

Pour un déploiement sous windows de WebView QML, j'ai été obligé d'ajouter QtWebProcess.exe en plus des DLL.