Et justement, ActiveState propose depuis des années un IDE basé sur la plateforme Mozilla, Komodo. Le problème est que cet environnement n'est pas libre et est payant, c'est pourquoi il n'est pas forcément très connu (pour l'anecdote, c'est eux qui sont à l'origine du binding XPCOM pour Python). Il y a depuis quelque mois une version "light" et gratuite, Komodo-edit, mais ce n'est toujours pas libre. Cependant, le groupe de travail Mozpad, qui oeuvre pour le développement de XulRunner et de son ecosystème, et qui réfléchi notamment à la mise en oeuvre d'un IDE pour aider à la réalisation d'applications XUL, avait Komodo dans son colimateur depuis quelques temps. En effet, quoi de plus naturel d'utiliser un IDE en XUL pour réaliser des applis XUL, surtout que, connaissant la techno, réaliser des extensions est plus facile que d'aller apprendre JAVA et tout le système de plugins complexe d'Eclipse. Mais le fait que Komodo soit propriétaire était bloquant pour s'en servir comme base d'un future IDE pour XUL.

Et voilà que, comme par une heureuse coïncidence[1], ActiveState décide de libérer sa plateforme IDE ! Le nom du projet : OpenKomodo.

OpenKomodo n'est pas un IDE à proprement parler, mais un framework, une base pour réaliser un IDE, s'appuyant donc sur les technologies Mozilla. Il aura tous les composants de base nécessaires à la création d'un IDE, restera alors plus qu'à réaliser des extensions et probablement l'interface principale pour créer un IDE. OpenKomodo sert d'ailleurs de base pour les produits Komodo-IDE et Komodo-Edit. Une première version publique sera disponible en novembre. Et un autre projet va démarrer, Komodo Snapdragon, qui sera un IDE spécialisé pour le développement d'application web.

Reste plus maintenant qu'à démarrer un projet d'IDE pour applis XUL, ce qui ne devrait pas tarder d'ici la fin de l'année, on peut compter sur des Mozpad'iens :-)

Seul bémol toutefois, après avoir testé la version linux de Komodo-edit cet aprés-midi : l'interface n'est pas très réactive, et ça rend son utilisation agaçante. Je soupçonne les composants en Python et peut-être aussi le binding XPCOM Python, d'être responsable de cette lenteur. Ce serait pas mal qu'à l'avenir, dans OpenKomodo, les composants les plus critiques soit converti dans un autre langage plus performant. Ou alors améliorer le binding Python. Le seul truc qui est très réactif, c'est la zone d'édition. Mais c'est normal, c'est un plugin basé sur l'éditeur scintilla, le même type de plugin qu'à fait Paul dans codeditor ;-)

Notes

[1] il est possible que le voeux de mozpad d'avoir un komodo libre ne soit pas étranger à la décision d'Activestate, mais ce n'est que pure supposition de ma part :-)