Les approximations sur KompoZer

« Si Kompozer a un succès mérité aujourd'hui, il reste que c'est Nvu™ à 99%. »

KompoZer 0.7, en 2006, était une proposition de bugfix pour Nvu visant à corriger les bugs les plus handicapants de l'application, donc effectivement c’était du Nvu à 99%. À l’époque, je découvrais le XUL et je bossais tout seul sur ce projet…

Mais nous sommes en 2010 aujourd'hui et KompoZer 0.8 n’a plus grand-chose à voir avec Nvu : il emprunte bien plus de code à SeaMonkey Composer qu’à Nvu. Et la version en développement (0.9) est bâtie à 100% sur SeaMonkey Composer.

KompoZer est devenu un vrai projet communautaire, ce que Nvu n’a jamais été. Si demain je me faisais écraser par un autobus (ou pire, si je trouvais un boulot salarié ^^), le projet continuerait sans moi — probablement moins vite, mais il continuerait. À l’inverse, quand Linspire a arrêté le support de Nvu, les forums d’assistance et de développement ont tout simplement disparu du jour au lendemain, avec toutes les données qu’ils contenaient.

« Nvu™ est obsolète. »

C’est complètement vrai, et je ne l’aurais pas relevé si le sous-entendu n’était pas que KompoZer était obsolète au même titre que Nvu. Mais maintenant qu’on en parle, pourquoi Nvu est-il obsolète ?

  • parce que son développement a été abandonné dès que le financement s’est arrêté, soit le jour même de la sortie de la version 1.0 ;
  • parce qu’il est construit sur un noyau Gecko 1.7 fortement modifié (15'000 lignes de patch), qui ne fonctionne plus sur les postes Mac ou Linux récents ;
  • corollaire : impossible de rétro-porter un tel code dans le tronc Mozilla (contrairement à ce qui avait été annoncé au départ du projet).

Parallèlement, SeaMonkey Composer a poursuivi son petit bonhomme de chemin. Il suit l’évolution du noyau Gecko (HTML5, CSS3, etc.), certes sans ajouter de fonctionnalités coté interface, mais avec une stabilité irréprochable : un bon exemple de projet pérenne car maintenu par la communauté Mozilla.

Le but qu’on poursuit avec le projet KompoZer c’est précisément de ramener le code dans le giron Mozilla. Toute la branche 0.8 est une étape intermédiaire qui consiste à supprimer le patch Nvu pour que la branche 0.9 soit intégrée directement au comm-central Mozilla. Les améliorations profiteront donc directement à SeaMonkey, indirectement à Thunderbird.

Nvu était obsolète “by design”, mais KompoZer et SeaMonkey Composer ne le sont pas — au contraire, ces projets font le choix de la pérennité. Ce sont des projets communautaires proches de Mozilla, on a déjà de nombreuses locales (22 pour Kompozer 0.8) et des contributeurs réguliers.

Les nouvelles fonctionnalités annoncées

« Aujourd'hui, il est temps de faire apparaître un outil d'édition plus moderne, offrant la puissance des versions récentes de Gecko et les fonctionnalités de CSS3 et HTML5. »

Tout comme SeaMonkey Composer, KompoZer 0.9 supporte déjà CSS3 et HTML5. Nul besoin de faire une nouvelle application pour supporter le dernier moteur Gecko en date, il suffit d’avoir une application qui soit respectueuse du code Mozilla — comme SeaMonkey et KompoZer ≥ 0.8.

KompoZer 0.9a1pre, CSS3 demo

KompoZer 0.9 est encore en pré-alpha précisément parce que je préfère rétro-porter toutes les fonctionnalités stables dans comm-central (SeaMonkey) *avant* de sortir une version publique. Avec l’équipe SeaMonkey, nous allons mettre en place un système de nightlies pour que les utilisateurs puissent se rendre compte de l’avancement du projet.

Tant qu’IE9 n’est pas sorti, je ne ressens pas d’urgence à proposer un éditeur web supportant CSS3 : il suffit de jeter un œil sur les forums de support pour se rendre compte que l’incompréhension la plus fréquente concerne les différences de rendu entre IE et les navigateurs modernes.

« Un des buts de l'amélioration de l'extensibilité est clairement la distribution au moment de la 1.0 de BlueGriffon d'un premier jeu assez étoffé d'add-ons »

Je ne pense pas que KompoZer soit difficile à étendre. Jean-Bernard “Goofy” Marcon, qui n’est absolument pas développeur, a déjà codé des petites extensions pour KompoZer 0.8 : http://addons.kompozer.net/

Par ailleurs, cinq étudiants du projet CoMETE réalisent des extensions KompoZer plus ambitieuses : http://labs.kompozer.net/

L’extensibilité de KompoZer est certes perfectible, mais la plus grosse marge de progression résiderait dans le fait de se rapprocher de Firefox autant que possible (typiquement, en exposant un gBrowser), afin de pouvoir porter facilement les nombreuses extensions Firefox qui sont orientées développement web.

Réciproquement, je crois qu’il faut aussi privilégier la réutilisation d’extensions existantes plutôt que de recoder une fonctionnalité dans son coin. À ce titre, c’est à ma demande et pour le projet KompoZer que les auteurs de FireFTP et ScribeFire ont accepté de changer de licence afin de les rendre totalement compatibles avec la base de code Mozilla. Les fonctionnalités de publication FTP et XML-RPC seront donc mutualisées, ce qui ne peut qu’améliorer la stabilité pour tous les utilisateurs.

Pour qu’un projet reçoive des extensions il faut aussi en assurer la pérennité : un projet maintenu par une personne seule n’est jamais viable à long terme. C’est la raison pour laquelle les équipes SeaMonkey et KompoZer travaillent en commun sur la branche 1.9.3, dans le but de reverser autant de code que possible sur comm-central — ce qui profite directement à SeaMonkey, indirectement à Thunderbird et potentiellement à Firefox.

Quel intérêt pour Mozilla ?

« longue vie à BlueGriffon™ ! »

Bien sûr, c’est ce que je souhaite à Daniel ; mais ça ne sera pas positif pour Mozilla.

Qu’est-ce que Nvu a apporté au projet Mozilla ? Absolument rien. Ce projet paraissait pertinent en 2005 puisqu’il fallait bien faire une version standalone de l’éditeur à l’heure où on séparait la Suite Mozilla en Firefox + Thunderbird ; mais de par sa conception, il était impossible de reverser le code au tronc Mozilla.

Est-ce que BlueGriffon sera différent ? Je ne le crois pas. Au contraire, là où Nvu n’était qu’un petit fork de la base de code Mozilla, BlueGriffon est une réécriture majeure, où même l’interface utilisateur a une base de code différente : les améliorations de BlueGriffon ne pourront pas être réutilisées dans Thunderbird ou SeaMonkey Composer.

Toutes les nouvelles fonctionnalités annoncées par Daniel pourraient être réalisées sur la base de code Mozilla — dont il est théoriquement responsable du module "editor", soit dit en passant. Je comprends bien que pour un investisseur, le modèle économique est plus rassurant avec un écosystème d’extensions distinct. Je comprends aussi qu’il est plus satisfaisant intellectuellement de développer une nouvelle application plutôt que de déboguer l’existant. Mais techniquement, il n’y a rien qui justifie de forker à nouveau la base de code Mozilla.

À plus long terme, il faut aussi se demander à quoi va servir un éditeur web WYSIWYG en 2010 : nombre d’utilisateurs débutants préfèrent publier leurs pages sur MySpace ou FaceBook, voire sur un CMS type WordPress, Joomla, Drupal ou autre. Les utilisateurs avancés, eux, n’ont pas l’utilité d’un éditeur WYSIWYG (inutilisable avec PHP, Python, etc.) et ont besoin avant tout d’un bon IDE comme Komodo — qui est lui aussi extensible et propulsé par Mozilla.

Je pense donc qu’il vaudrait bien mieux viser à avoir un éditeur web WYSIWYG stable et pérenne car débogué en bonne intelligence avec les autres développeurs Mozilla, et développer un écosystème d’extensions qui soient compatibles avec Firefox et/ou Komodo. L’éditeur CSS en est un très bon exemple. Et je ne vois pas en quoi ça serait incompatible avec le modèle économique de Daniel.

Quelles conséquences pour KompoZer ?

À priori aucune si BlueGriffon n’utilise pas la base de code comm-central. Le but de KompoZer 0.8+ étant de pérenniser le développement en le rétro-portant sur comm-central, je ne pourrais que regretter que le talent et l’énergie de Daniel ne contribuent pas à cet objectif, mais il serait dommage de s’arrêter si près du but.

En revanche, si BlueGriffon utilisait la base de code comm-central pour l’interface de base et implémentait les fonctionnalités spécifiques dans des JSM séparés, il serait bénéfique pour tout le monde que le projet KompoZer s’efface au profit de BlueGriffon et SeaMonkey Composer : mon temps serait alors bien mieux employé à contribuer à ces deux projets.

Contribuer

Si vous souhaitez contribuer à KompoZer *et* à l’éditeur Mozilla, vous pouvez nous rejoindre sur le canal #kompozer.

Mise à jour : voir aussi l’entretien que m’a accordé Tristan. :-)