Pour sa version 5.6, Qt officialisait l’abandon du module Qt WebKit, qui intégrait un moteur de rendu Web dans des interfaces Qt : WebKit, le moteur de Safari et dont dérive celui de Chrome (Blink). Ce module a été remplacé par Qt WebEngine, qui se base sur un moteur bien plus complet : Chromium, intégrant à la fois une pile réseau et multimédia. Qt WebEngine est bien plus lourd et monolithique que son prédécesseur, ce qui n’est pas sans poser quelques problèmes de distribution.De plus, le passage de Qt WebKit à Qt WebEngine ne se fait pas sans douleur, puisque les interfaces sont assez différentes et que Qt WebEngine ne fournit pas le même degré d’intégration à Qt. Aussi, Qt WebEngine n’est pas exploitable à un niveau assez bas, pour travailler directement dans le DOM ou effectuer un rendu hors écran, ce qui est très utile pour toutes les applications devant traiter des pages Web.
C’est pourquoi certains développeurs se sont lancés dans un projet de réhabilitation de Qt WebKit, en mettant à jour la version utilisée du moteur tout en gardant la même API et ABI. Bien que ce projet soit encore à l’état embryonnaire, cette mise à jour apporte bon nombre d’avantages par rapport aux dernières versions officielles du module, notamment au niveau des fonctionnalités disponibles en JavaScript (une bonne partie d’ES2015) et des API HTML5 (WebAudio, images adaptées à la résolution). Le développement est loin d’être terminé : l’API widgets est relativement prête, mais pas du tout côté QML. Des API HTML5 comme IndexedDB et WebGL ne sont pas disponibles, ni les extensions (tant côté Qt que NPAPI).
Cependant, au niveau des plateformes compatibles, la liste s’amenuise par rapport à l’itération précédente de Qt WebKit : pas d’Android, de QNX ou de WinCE. L’un des freins au module existant était la nouvelle API de WebKit, mais les développeurs de ce nouveau projet ne sont pas sûrs de travailler sur une compatibilité avec Windows pour cette API WebKit 2. De plus, les développeurs de WebKit ont une politique nettement plus agressive au niveau des normes C++ utilisables dans leur code : ils sont passés depuis longtemps à C++11 (alors que Qt s’apprête seulement à franchir ce pas avec Qt 5.7) et C++14 dans les versions de développement actuelles. En d’autres termes, le choix de compilateurs se restreint.
Pour toutes ces raisons, il apparaît de manière relativement claire que ces efforts ne pourront pas se faire sous le nom de Qt WebKit, pour éviter la confusion avec le module précédent : ces efforts pourraient se nommer WebKitQt (comme les autres ports de WebKit) ou Qt WebKit NG (le nom de code interne actuel). En plus d’autres considérations pratiques, comme un alignement sur WebKitGTK, le planning des versions ne sera que rarement aligné sur celui de Qt. Par conséquent, WebKit ne fera probablement jamais son retour parmi les modules distribués d’office avec Qt, mais plutôt comme extension, téléchargeable à la carte… ce qui n’empêchera pas le développement sous l’ombrelle du Qt Project.
Sources : [Development] QtWebKit is coming back, [webkit-qt] [Announcement] QtWebKit Technology Preview 1.
Voir aussi : le site de Qt WebKit Reloaded.
Ce contenu a été publié dans Qt par dourouc05.
