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 ?