Le retour de Qt WebKit ?

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).

http://tcuvelier.developpez.com/news...1/features.png

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.

Je pense que webkit1 est necessaire pour les applis hybrides, pas besoin d'isolation des processes, il faut pouvoir controler les flux, avoir une api pour chercher les elements cotes c++ car c'est tres penible de le faire en javascript. Qt s'est un moment trop concentré sur webkit2 qui ne touchait presque personne et ils avaient deprecié tout ce qui etait utile pour les applis hybrides. D'ailleurs, la preuve est que cocoa (macos) ne propose que webkit1 a embarquer dans les applis.

De plus je n'ai pas compris ce choix d'aller avec blink. On sait tous que google n'est pas un bon choix, l'experience avec V8 aurait quand meme pu leur mettre la puce a l'oreille.

Alors merci aux personnes qui reprennent webkit, je pense que ca va avoir un grand succes.

L'effort est grandement appréciable.

J'espère juste que QtWebEngine ou QtWebkit arriveront un jour à avoir un tuto complet et/ou puissent compiler sur Raspberry Pi. Avec la version 5.6, je ne suis pas encore arrivé à utiliser un seul module pour afficher du HTML...

Peu après les premières annonces officielles, une nouvelle préversion technologique du nouveau Qt WebKit fait son apparition. Dans les nouveautés, on peut compter une implémentation de l’API HTML5 IndexedDB complètement refaite : elle ne dépend plus de LevelDB, un moteur de base de données de Google, tout en apportant un meilleur niveau de compatibilité avec la norme.

Pour les vidéos, l’API Media Source Extensions est activée quand GStreamer est disponible. Cette implémentation est encore expérimentale et, notamment, toutes les vidéos YouTube ne fonctionnent pas (lorsqu’une publicité est affichée au début). Il faut encore l’activer manuellement, mais elle devrait l’être automatiquement dans une prochaine version.

D’autres API sont maintenant disponibles : la détection de l’orientation et des mouvements, principalement pour les applications mobiles ; les manettes de jeu, uniquement pour Linux. Aussi, il devient possible d’imprimer. Le projet est maintenant compatible avec OS X 10.10.

Au niveau de l’infrastructure, le projet s’intègre mieux avec qmake et CMake, ce qui facilite son utilisation dans vos projets. La documentation est maintenant générée aux formats HTML et QCH, ce qui permet notamment son utilisation depuis Qt Creator ou Qt Assistant.

Maintenant, des binaires précompilés sont disponibles : pour Windows 32 et 64 bits (compilation avec Visual C++ 2015) ainsi que pour OS X.

http://tcuvelier.developpez.com/news...2/features.png

Source : [Development] [Announcement] QtWebKit Technology Preview 2.
Ce contenu a été publié dans Qt par dourouc05.

Le projet continue à revivre, entièrement dans la communauté (sans soutien de la part des développeurs principaux de Qt) : Qt WebKit nouvelle génération voit une troisième préversion technique (TP3) arriver. L’une des grandes nouveautés de cette version est la compatibilité avec les extensions NPAPI et Qt (uniquement pour Windows et X11, pas de macOS pour le moment).

Une partie du travail a consisté à s’approcher du niveau de fonctionnalité de Qt WebKit : les balises <object> et <embed> peuvent gérer du contenu avec des images, l’élément <progress> fonctionne comme attendu, les liens <a> peuvent utiliser l’attribut download. L’API Web SQL Database était malencontreusement désactivé, ce qui est corrigé.

Aussi, les développeurs ont ajouté d’autres fonctionnalités par rapport au module Qt WebKit précédent : les événements DOM de niveau 4, la propriété CSS -webkit-initial-letter (qui nécessite Qt 5.8, les raccourcis pour les polices système.

De manière plus générale, la plupart des modifications proposées sur Gerrit depuis Qt 5.2 ont été intégrées : bon nombre de défauts avaient été corrigés par la communauté, sans être intégrés dans le code de Qt WebKit. Il devient aussi possible de compiler Qt WebKit NG sous forme statique, avec les bibliothèques statiques de Qt.

Télécharger Qt WebKit NG TP 3.
Ce contenu a été publié dans Qt par dourouc05.

Le projet de renouveau du module Qt WebKit en est à sa cinquième préversion. Celle-ci continue à remettre le module Qt WebKit au goût du jour, apportant les dernières fonctionnalités de WebKit à Qt 5. En effet, depuis l’introduction de Qt WebEngine, qui utilise Chromium comme moteur Web, Qt WebKit n’a plus été mis à jour — alors qu’il répond à un certain besoin, au vu de son intégration de grande qualité avec Qt et de ses prérequis très légers (juste un compilateur C++11).

L’API plein écran de HTML5 est maintenant implémentée. Du côté de l’API C++, QWebPage dispose maintenant du signal focusedElementChanged. Sous Windows, les contenus vidéo peuvent être joués par Media Foundation (l’API système) au lieu de Qt Multimedia ; d’ailleurs, il est désormais possible de compiler Qt WebKit avec MinGW. WebGL et le dessin accéléré par GPU pour la balise canvas sont de retour dans Qt WebKit (ces fonctionnalités étaient présentes du temps de Qt 4/5.4, mais étaient perdues lors de la réécriture du module).

Des binaires sont disponibles pour Qt 5.8. Le seul gros point restant à travailler pour atteindre les objectifs des développeurs est une API QML pour WebKit2 (le travail d’implémentation a déjà démarré). Avant une réintégration au sein du projet Qt ? Les doutes sont permis, cette nouvelle préversion étant prévue pour s’intégrer aux scripts d’intégration continue de Qt.

Source : QtWebKit Technology Preview 5, la liste de diffusion de Qt.

Bien de l’eau a coulé sous les ponts depuis l’annonce du renouveau du port Qt de WebKit. La culmination d’un de travail a mené ce chantier au point où le nouveau module Qt WebKit peut à nouveau être utilisé sans arrière-pensée dans un nouveau projet, en remplacement du module précédemment désapprouvé. La version TP 5 est sortie depuis février et est déjà proposée par des distributions comme Arch Linus ou MSYS2 (KaOS va plus loin et remplace même d’office le module précédent par cette nouvelle implémentation). La première Alpha pourrait ainsi sortir sous peu.
Les objectifs principaux sont ainsi atteints : au niveau des fonctionnalités, il n’existe plus de différence flagrante par rapport au module désormais désuet. Le seul bémol est l’API QML pour Windows, qui fonctionne mais n’est pas encore disponible dans cette TP 5. Il manque certes encore quelques points mineurs dans cette API QML.

https://i1.wp.com/tcuvelier.developp...ebKitNGTP5.png

Cette version TP 5 est totalement intégrée au sein du Qt Project : un clone du dépôt Git du projet y est hébergé, les tests sont lancés régulièrement dans l’infrastructure COIN de Qt. Les discussions sont en cours pour le moment pour intégrer cette nouvelle version de Qt WebKit dans la distribution courante de Qt.
Télécharger Qt WebKit NG TP 5.
Source : liste de diffusion de Qt.

Avez-vous plus de nouvelles concernant cette potentielle réintégration ?

Je travaille sur un projet open-source basé sur Qt 5.5.1 et je commence l'étude d'un portage vers 5.9 (voire plus).

Ma problématique est la suivante : une grosse partie du code repose sur l'utilisation de QGraphicsWebView, qui n'est tout simplement pas supporté par WebEngine.

Citation:

---

Qt WebEngine is designed for being used with hardware acceleration. Because we could not support a web view class in a QGraphicsView unless it would be attached to a QGLWidget viewport, this feature is out of scope

---

Je me demande sérieusement si le maintien de Qt WebKit comme une dépendance tierce dans ce projet pourrait être une solution acceptable (voire recommandée si bientôt de retour dans Qt).

Le repo git n'a pas l'air de beaucoup bouger depuis 2017 vous savez pourquoi ?

Pour information, le développement a repris activement.

https://forum.qt.io/topic/102816/webkit-status-2019
https://github.com/qtwebkit/qtwebkit/issues/812

Pour le moment, le développeur a suffisamment de financement pour garantir que Qt WebKit fonctionnera sous Linux et, dans une moindre mesure, sous Windows. Si vous souhaitez le supporter : https://www.patreon.com/annulen

Le développement de Qt WebKit reprend,
la dernière version de WebKit est déjà intégrée avec le support de Linux, Windows et macOS

Suite à une campagne de crowdfunding couronnée de succès, le développement de Qt WebKit a repris activement.

Le support de cette bibliothèque historique, remplacée par Qt en 2016 au profit du WebEngine, sera assuré pour Linux, Windows et macOS.

QtWebKit 5.212.0 Alpha 3 a été publiée (et des binaires pour Qt 5.13 sont déjà disponibles pour les trois plateformes), incluant les progrès réalisés sur la branche qtwebkit-5.212 avant l'interruption de 2018, tous les correctifs épars faits par le développeur principal, Konstantin Tokarev, en 2018, ainsi que de nouveaux développements réalisés par ce dernier et Michał Dutkiewicz.

Les problèmes de compilation de Qt WebKit avec les mises à jour récentes de MSVC 2017 ont finalement été résolus, ainsi que les problèmes de compilation sur macOS 10.14.

Une nouvelle branche a été créée (qtwebkit-dev) et fusionnée avec le tronc WebKit. Cela signifie que la branche Qt WebKit est enfin à jour et donc exempte de toutes les vulnérabilités connues de WebKit (le moteur web utilisé par Safari).

Konstantin Tokarev précise toutefois qu'il y a un inconvénient : la plupart du code n'est pas encore compilé et il est déjà connu que certains éléments de code nécessiteront d'importantes modifications pour fonctionner. Ce travail a commencé en juillet et avance assez vite.

Les développeurs du portage Qt de Webkit ont également bénéficié de l'intervention d'Ashish Kulkarni (auteur du logiciel wkhtmltopdf), qui les a aidés à créer une organisation GitHub, un serveur CI dédié et un miroir git-svn automatique des branches WebKit, permettant de simplifier la maintenance des branches stables à l'avenir.

Des tests et une infrastructure d'assurance qualité sont en cours de réalisation : Michał Dutkiewicz travaille actuellement sur la mise en place de tests pour l'API widgets.

Certains travaux ont été effectués pour améliorer la gestion des dépendances tierces sur Windows. Konstantin Tokarev précise que tous les packages seront construits automatiquement et très peu de travail manuel sera nécessaire pour les mises à jour logicielles. Cela signifie que les utilisateurs de Qt WebKit disposeront toujours des versions les plus récentes et les plus performantes de ICU, libxml2 et libxslt, livrées avec les versions Windows de Qt WebKit.

Vous pouvez soutenir le projet ici : https://www.patreon.com/annulen

---
Sources :
https://www.patreon.com/posts/hello-world-28061255
https://github.com/qtwebkit/qtwebkit/issues/812
https://forum.qt.io/topic/102816/webkit-status-2019

Et vous ?

:fleche: Qu'en pensez-vous ?

:fleche: Quelles sont les nouveautés attendues ?

:salut:


Est-ce qu'une version Windows MinGW sera prévue ? Je ne vois rien dans les binaires. Peut-être faut-il partir des sources et faire soi-même la compile. Mais est-ce facilement réalisable ?


Ciao.


J

Aux dernières nouvelles, WebKit2 ne pouvait pas être compilé avec MinGW, sauf à chipoter dans tous les sens… Ou alors ça a récemment changé ?