En effet, il pense que ça va permettre l'utilisation des "plugins" Firefox dans Konqueror, puisqu'ils sont fait en XUL :

Once XUL support is added, it should not be too difficult at all to support Firefox plugins in my favorite KDE web-browser.

En lisant cette phrase, je me dis que ce garçon n'a pas du vraiment regarder ce qu'était un plugin dans Firefox, ni comment les extensions et XUL fonctionnaient. J'ai bien peur qu'il n'aille pas bien loin dans son projet.

En effet, en premier lieu, il confond plugin et extensions. Un plugin dans Mozilla est un bout de programme externe qui permet d'afficher dans une page web (XUL ou HTML) le contenu d'un type de document non supporté nativement par Mozilla : cela peut être du flash, des vidéos etc... Bref, un truc qui s'affiche via une balise <object> en HTML. Il n'y a donc pas la moindre balise XUL dans un plugin. Juste une interface programmative pour communiquer avec Mozilla.

Je suppose donc qu'il parle des extensions. En deuxième lieu, il pense que, parce que Konqueror saura afficher du XUL, il pourra alors utiliser les extensions Firefox. Je lui souhaite bien du courage. Déjà qu'une extension pour une version X de Firefox ne fonctionne pas toujours avec une version Y, alors pour fonctionner dans un navigateur autre que Firefox...

Pourquoi ne serait-ce pas possible ? Tout simplement parce que l'intégration de la majorité des extensions dans le navigateur dépend totalement de l'interface de Firefox. Changez quelques balises XUL dans cette dernière, et votre extension risque bien de ne plus fonctionner. En effet, cette intégration repose sur le mécanisme des overlays. Ce mécanisme est relativement simple à comprendre. Vous avez d'un coté un fichier XUL, donc du XML, décrivant par des balises XML la structure de votre interface graphique principale. Et d'un autre coté, des fichiers, les overlays, eux aussi en XML, indiquant quelles balises du fichier principal doivent être modifiées, et ce qu'il faut rajouter au niveau de ces balises.

On comprend alors aisement qu'un overlay est trés lié à la structure du fichier principal, et que si les balises que l'on veut modifier n'existent pas/plus dans le fichier principal, les modifications dans l'interface graphique vont être mal appliquées, voire pas du tout.

Permettre donc d'utiliser les extensions de Firefox dans Konqueror impliquera deux choses :

  1. que l'interface de Konqueror soit en XUL
  2. que le fichier XUL de l'interface de Konqueror soit identique à celui de Firefox

Pour le premier point, je vois mal cela se concrétiser, ou plutôt être accepté par KDE. En effet tout programme KDE utilise la bibliothèque QT pour afficher leur interface graphique. Or qui dit interface en XUL, dit qu'il va falloir faire appel au browser pour afficher l'interface en XUL. En effet, la fenêtre de Firefox, de thunderbird etc, n'est finalement qu'un navigateur, affichant un fichier XUL, pouvant comporter lui même (en simplifiant) une ou plusieurs iframes pour afficher/éditer une page web dans le cas de Firefox/Nvu. Bref, tout cela implique de modifier la façon de développer les applications KDE.

En admettant toutefois qu'il y ait exception pour le navigateur Konqueror (ou même, ce qui serait absolument fantastique, que les interfaces de tous les programmes KDE reposent sur du XUL et utilisent le moteur de Konqueror pour afficher leur interface), il va falloir que Konqueror ait absolument la même interface que Firefox : même menus, même barres de boutons etc.. Tout ce qui fait donc la spécificité de Konqueror va disparaitre (il pourra toujours ajouter des trucs en plus, mais il faudra tout de même avoir comme base le fichier XUL de Firefox). On aura donc un clone de Firefox. J'entend déjà des utilisateurs de Konqueror crier au massacre...

Et il n'y a pas que ça. Permettre l'utilisation des extensions Firefox, cela implique aussi de :

  1. supporter le langage XBL puisque bon nombre de balises XUL sont basées sur des composants XBL, ce qui permet à XUL d'être extensible au niveau de balises ( d'où d'ailleurs l'absence de DTD ou schema XML décrivant XUL, et sa constante évolution dans le temps );
  2. supporter le système de thèmes et de localisation de Firefox, (les urls "magiques" de type chrome:://foo/skin/, chrome://foo/locale/) puisque le design des extensions dépend des thèmes installés sur Firefox et de la langue utilisée ;
  3. supporter tous les styles CSS propriétaires à Gecko, dédiés aux balises XUL (-moz-box-flex, -moz-box-orient etc..);
  4. intégrer XPCOM et tous les objets XPCOM de Firefox, utilisées par bon nombre d'extensions (ou alors en simuler l'API), ce qui ne va pas être facile puisque l'API et le nombre d'objets XPCOM évolue à chaque version et il y en a... beaucoup ;
  5. supporter le format RDF, les templates XUL, et les sources de données RDF fournies par Firefox

En clair, permettre l'utilisation des extensions de Firefox, revient à ... cloner Firefox de A à Z, de l'interface jusqu'aux entrailles du navigateur, en implementant toutes les technologies de Mozilla. Ce qui est plutôt ridicule à mon sens.

Autant permettre l'affichage de page XUL dans le navigateur, en supportant un minimum de techno de Mozilla, est faisable (sans être 100% compatible), autant offrir la possibilité d'utiliser les extensions de Firefox est utopique en dehors de Firefox. En tout cas, je n'y crois guère.

Un projet de bilbiothèque permettant d'afficher des fichiers XUL dans KDE avait démarré en 2003 : KaXul. Mais il n'était pas trés avancé, et il lui manquait encore beaucoup de choses pour arriver à quelque chose de potable. D'ailleurs, il n'a plus évolué depuis, si on en croit les dates des fichiers dans subversion. Je suis prêt à parier que le manque de temps n'est pas la principale cause de ce gel ;-)

Pour ce projet, google a de forte chance d'économiser 4500$, car dans tous les cas, implementer tout ça ne se fera pas en 2 mois comme l'impose les rêgles du concours. Mozilla ne s'est pas fait en 2 mois... Il a fallu quelques années aux ingénieurs de la fondation pour le faire...