Webkit est fourni sous la forme d'une api multiplateforme d'assez bas niveau, qui gère uniquement le rendu/le dom/JavaScript. Par dessus, il y a différents bindings, pour divers toolkits graphiques :
une api cocoa
webkitGTK, notamment utilisé par epiphany, le navigateur de GNOME, mais aussi par le visionneur de doc GNOME et apparemment bientôt par Évolution
Qtwebkit, utilisé par rekonq notamment
La sauce google utilisé dans chrome.
Dans la version dite "1" de l'API webkit de base, il n'y a qu'un seul processus qui gère le rendu. Par dessus, on peut implémenter le processus qui gère l'UI, c'est ce que simplifient les différentes API pour les divers toolkit. Google a décider avec chrome de séparer cette UI dans un autre processus, mais ce n'est pas géré par webkit, c'est leur propre sauce, ce n'est pas trivial à implémenter avec n'importe quelle API webkit.
Cela dit, il y a une nouvelle version de l'API de base, webkit2, sortie en 2010. Cette version inclue directement dans l'API webkit de base un modèle similaire à chrome, séparent le contenu de l'UI dans des processus séparés, et pouvant placer divers contenus dans divers processus.
WebkitGTK a un support en court de stabilisation de webkit2 et gnome a annoncé vouloir sortir une version beta d'épiphany avec webkit2 pour GNOME 3.6. J'imagine que ça va arriver aussi sous KDE/rekonq.
Donc, pour résumer, même si tu ne parlais que des plugins et non de tout les contenus, non, ce n'est pas trivial à faire à moins de porter le navigateur vers la nouvelle API. Sinon il faut bricoler soit même.
[^] # Re: Rekonq
Posté par Enjolras . En réponse à la dépêche Rekonq 1.0. Évalué à 10.
Webkit est fourni sous la forme d'une api multiplateforme d'assez bas niveau, qui gère uniquement le rendu/le dom/JavaScript. Par dessus, il y a différents bindings, pour divers toolkits graphiques :
Dans la version dite "1" de l'API webkit de base, il n'y a qu'un seul processus qui gère le rendu. Par dessus, on peut implémenter le processus qui gère l'UI, c'est ce que simplifient les différentes API pour les divers toolkit. Google a décider avec chrome de séparer cette UI dans un autre processus, mais ce n'est pas géré par webkit, c'est leur propre sauce, ce n'est pas trivial à implémenter avec n'importe quelle API webkit.
Cela dit, il y a une nouvelle version de l'API de base, webkit2, sortie en 2010. Cette version inclue directement dans l'API webkit de base un modèle similaire à chrome, séparent le contenu de l'UI dans des processus séparés, et pouvant placer divers contenus dans divers processus.
WebkitGTK a un support en court de stabilisation de webkit2 et gnome a annoncé vouloir sortir une version beta d'épiphany avec webkit2 pour GNOME 3.6. J'imagine que ça va arriver aussi sous KDE/rekonq.
Donc, pour résumer, même si tu ne parlais que des plugins et non de tout les contenus, non, ce n'est pas trivial à faire à moins de porter le navigateur vers la nouvelle API. Sinon il faut bricoler soit même.