KompoZer n’est pas Nvu
By Kazé on Wednesday, April 7 2010, 01:35 - Permalink
Daniel Glazman a annoncé qu’il avait trouvé un financement pour BlueGriffon. J’aimerais pouvoir en dire autant pour KompoZer, mais je ne peux que m’associer à la joie de Daniel qui va à nouveau connaître le rêve de tout libriste : être payé pour bosser sur son domaine de prédilection.
En revanche, j’ai sérieusement tiqué en lisant l’entretien publié par Tristan sur son blog. J’ai longtemps hésité à réagir (pas envie de déclencher une flame war), mais la réaction des autres contributeurs KompoZer m’impose de répondre à quelques points en particulier.
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.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. :-)
Comments
Tu le sais déjà mais il est bon de le rappeler, tu as tout mon soutient et je pense ne pas me tromper en avançant que tu as celui du reste de la communauté Mozilla francophone.
Alors comme ça, "il n’y a rien qui justifie de forker à nouveau la base de code Mozilla."… Mais qui a parlé de forker ? Pas moi. Je ne forke rien.
"KompoZer 0.9 supporte déjà CSS3 et HTML5"… Oui. Il "supporte" CSS3 et HTML5. Il ne les gère pas. Prenons un exemple tu veux ? "border-radius" est en Candidate Recommendation. On a donc le droit de supprimer le préfixe. Or pour l'instant, Gecko préserve le -moz- devant. Explique-moi comment KompoZer va éditer les deux versions ? Voire les 3 si tu veux gérer -webkit- aussi ? Tu me montres les spécificités d'UI relatives à HTML5 ?
"le projet continuerait sans moi" Parce que tu ne touches pas ou très peu aux couches profondes de l'édition, parce que tu n'as pas touché au Transaction Manager, parce que tu n'as pas eu vraiment besoin de travailler sur les editorListeners. Il faut environ six mois de pratique continue pour maîtriser tout ça. Prenons un exemple : certaines modifications du document ne sont pas gérées par le Transaction Manager (ie ne sont pas undoables). Quelqu'un est capable de rajouter ça dans tous les cas ? Y compris par exemple pour les modifs de feuille de styles ?
"un projet maintenu par une personne seule n’est jamais viable à long terme" Mais c'est bien pour cela que j'ai des embauches de prévues...
"ça ne sera pas positif pour Mozilla" Là, tu es vraiment gonflé... Et c'est marrant, je reviens de Mountain View où on n'avait pas exactement la même opinion. Marrant également, mon investisseur n'a pas non plus la même opinion.
Maintenant, il se trouve que je peux aisément lister ici en moins de vingt secondes une dizaine de raisons techniques absolument fondamentales et une dizaines de très grosses raisons UI pour lesquelles Kompozer ne peut aisément être revampé, en tout cas pour un coût non prohibitif. Je suis un ingénieur logiciel et une partie de mon métier, c'est de savoir reconnaître quand un soft est dans une boucle finale, que sa vie coûte plus que sa réécriture. Ce qui est le cas ici.
Je ne nie en aucun cas l'énorme boulot fait, la communauté construite, la reconnaissance acquise, l'utilité de Kompozer. Je ne l'ai d'ailleurs jamais nié.
"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".
BlueGriffon est sur la base de mozilla-central et va évidemment implémenter un maximum via des JSM (même si ces derniers ne sont pas encore dans le svn). Je l'ai d'ailleurs déjà dit. Cela devrait donc aider pour Seamonkey.
"Les améliorations profiteront donc directement à SeaMonkey, indirectement à Thunderbird". Je crois que tu n'as pas compris une chose que j'ai discutée à Mountain View la semaine dernière. Bespin m'a ouvert les yeux sur un point : nsHTMLEditor doit probablement mourir. Il faut envisager désormais sérieusement de laisser tomber nsHTMLEditor et d'écrire un éditeur HTML **en JavaScript** sur la base du seul nsPlaintextEditor. Il serait alors maintenable, extensible, overridable, tout ce qui fait défaut à nsHTMLEditor. Seule une fonction resterait probablement en c++, la manipulation d'anonymous nodes d'édition genre grippies, coins sensibles, etc. Dans le même temps, cela permettrait certainement de débloater Gecko et d'éliminer un assez grand nombre de bugs architecturaux.
Je pense moyen et long terme. Je pense à faire évoluer l'architecture de l'éditeur de Mozilla. Et je ne pense pas me tromper.
Oula, ça commence bien !
Slt à tous,
J'ajoute mes 10cents.
Je pense que la création d'un éditeur 100% JS et portable sur le web est effectivement la meilleure chose qui puisse arriver pour tous.
Les développeurs comme les utilisateurs finaux, comme très justement dit plus haut, utiliserons de moins en moins des outils comme NVU, Kompozer ou encore BlueGriffon.
Il ne manque pas grand chose, en fait, pour créer cela. Quand j'ai commencé BBComposer pour les besoins de ma petite boîte, je me suis naturellement basé sur Firefox et son éditeur intégré.
J'ai effectivement commencé par utiliser les fonctions internes, de mémoire, goDoCommand('bold'). Mais, je n'étais pas satisfait à cause du code pourri qu'il produisait et de mon exigence d'avoir du XHTML Strict.
J'ai donc commencé par effectuer des traitements après l'exécution de ces commandes, mais le code était tout simplement pas maintenable et le code de Gecko changeait à chaque version.
J'ai donc décidé de tout réécrire from scratch juste avec DOM et Js. Aujourd'hui, j'ai un code qui se passe presque totalement de nsHTMLEditor, en fait, il ne se sert de ce dernier que pour afficher le curseur (il existe aucune méthode pour demander à afficher le curseur en JS à part le rendre éditable).
Le undo/redo est complètement ré-implémenté en JS tout comme toutes les commandes habituellement nécessaires quand on édite du HTML/CSS.
L'avantage ? Une portabilité complète vers d'autres navigateurs supportant HTML5 (le drag n' drop utilise l'API HTML5) et ECMAScript dans ses dernières versions. Seul le copier coller utilise encore les API spécifiques à Firefox, les fameux composants XPCom, mais c'est en attente de qqchose du côté de HTML5.
Le code est en GPL et dispo ici : http://bitbucket.org/nfroidure/bbco...
Bref, je pense que c'est la meilleure voie à emprunter et je vous encourage à le faire, tout comme je me joindrai à une initiative de regroupement autour d'un tel projet avec mon expérience dans le développement de BBComposer.
@+ et bon courage pour la suite.
Un billet bien écrit permettant de mieux cerner les objectifs à long terme de KompoZer.
Cependant, je ne suis pas totalement d'accord avec toi en ce qui concerne l'intérêt d'un éditeur WYSIWYG en 2010.
Certain utilisateurs profiteront d'un tel outil pour se perfectionner dans la réalisation de sites web plus "personnalisés" que si ils avaient employé un CMS type Joomla.
L'editeur WYSIWYG est selon moi un des meilleurs moyens de s'initier au développement web quand on a aucune base. En commençant par utiliser uniquement l'outil graphique, on en vient souvent à essayer de modifier des portions de code dans la vue "source" et, pour les plus curieux, on se décide à apprendre à tout coder soit même.
Pour ma part c'est ce qui m'a fait tomber dans la "marmite du développement web" et de fil en aiguille à m'orienter vers le développement en général.
Voilà sinon ton analyse sur Blue griffon s'avère très instructive et clarifie pas mal de choses car il est vrai que l'interview de Daniel par Tristan avait tendance à faire un sérieux amalgame entre KompoZer et NVU. Amalgame négatif car présentant KompoZer comme obsolète au même titre que NVU.
Salut Daniel,
Pour l’instant il n’y en a effectivement pas, mais je ne vois pas ce qui m’empêcherait de les implémenter dans la base de code actuelle.
Idem pour CSS3 : même en conservant CaScadeS (ce qui n’est pas un but en soi), je pourrais me contenter de modifier le “sérialiseur” CSS pour qu’il génère des équivalents -webkit pour chaque propriété -moz (et virer les préfixes -moz quand c’est possible). L’utilisation de ton parser CSS en JavaScript serait évidemment plus propre, notamment pour conserver les commentaires, mais là encore je ne vois pas en quoi ça ne serait pas faisable sur la base de code actuellement partagée par Kompozer, SeaMonkey et Thunderbird.
Je ne nie pas le fait que le code pourrait être mieux organisé ; je dis juste qu’en l’état, je ne vois pas de raisons impératives à abandonner cette base de code.
La formule est peut-être un peu sèche mais elle traduit ma pensée… et ce que j’ai retenu de l’expérience Nvu. Pour faire simple, j’aurais pu poser la question dans ce sens : si la base de code est différente de celle de SeaMonkey Composer, comment ces travaux vont-ils pouvoir profiter au comm-central ?
Ou pour être encore plus clair : est-ce possible de développer le cœur de BlueGriffon directement sur comm-central, en partageant un max de code avec SeaMonkey et Thunderbird ? C’est ce qu’on s’apprête à faire pour Kompozer 0.9, si tu as un meilleur projet pour comm-central ça m’irait encore mieux ! Je ne vois malheureusement pas comment la refonte de l’architecture du projet est compatible avec une intégration dans comm-central.
+42 pour l’éditeur HTML en JS, à condition qu’il soit sur les dépôts Mozilla — et pas juste sur tes dépôts BlueGriffon. Je sais que c’est du boulot, mais je suis mono-maniaque : je pense qu’un éditeur web WYSIWYG propulsé par Mozilla doit servir à tout comm-central, et pas juste aux utilisateurs BlueGriffon / Kompozer.
Hello,
Je viens de publier l'entretien que nous avons réalisé tous les deux : http://standblog.org/blog/post/2010...
Par ailleurs, tu écris :
> je pense qu’un éditeur web WYSIWYG propulsé par Mozilla doit servir à tout comm-central, et pas juste aux utilisateurs BlueGriffon / Kompozer.
C'est du logiciel Libre, donc Daniel a le droit de faire ce qu'il veut dans la mesure où il respecte les licences du code qu'il reprend. Par contre, s'il ne reverse pas à comm-central, je pense que la communauté existante sur l'éditeur ne contribuera pas à BlueGriffon avec le même entrain, c'est évident.
Merci Tristan. :-)
J'ai répondu à tout ça sur le blog de Tristan mais une réponse technique s'impose ici : ta solution de resérialisation de -moz- en -webkit- est insuffisante. Et tu fais quoi si les CSS d'origine ne contiennent que du -webkit-* ? L'usager se fout que Kompozer soit sur base Mozilla, il veut éditer sa page et TOUTE sa page. Or c'est jeté par le parser, tu ne le vois donc même pas et tu ne peux pas l'appliquer au document ni le modifier. Tu le gères donc comment ? Changer l'architecture actuelle pour faire ça ? Woof.
Certes, mais les pages contenant des propriétés CSS en -webkit-* sans les équivalents -moz-* ne doivent pas être légion quand même ! Par ailleurs, si tu veux garder un éditeur CSS wysiwyg, il faudra bien utiliser ce genre d’astuce de sérialisation à un moment donné pour que les propriétés CSS3 soient vues par tous les navigateurs compatibles.
Je l’ai écrit plus haut : ton parser CSS offre de bonnes perspectives et permettrait d’outrepasser certaines limitations agaçantes du parser Gecko, je ne mets pas ça en doute et j’en vois très bien l’intérêt (notamment pour préserver les commentaires) ; par contre, je ne vois pas pourquoi il faudrait changer toute l’architecture Composer pour utiliser ton parser CSS. Même chose pour l’éditeur CSS en général : je suis bien conscient du fait qu’il y a une marge de progression énorme sur cet éditeur, mais je ne vois pas pourquoi il faudrait renoncer à l’architecture actuelle de l’éditeur HTML pour avoir un nouvel éditeur CSS.
D’une manière générale, je pense qu’un éditeur CSS avancé a moins d’intérêt dans Composer que dans Firefox ou Komodo. Au minimum, un éditeur CSS avancé en XUL gagnerait grandement à être compatible avec Firefox, Komodo et Composer. Pour le coup, ma religion ne m’impose pas de développer un tel éditeur CSS dans le dépôt comm-central, puisqu’on n’a plus d’éditeur CSS dans les dépôts Mozilla et parce que c’est sans intérêt pour Thunderbird… et rien ne t’empêcherait de garder une version FLOSS de cet éditeur CSS, et d’en vendre une version avancée pour BlueGriffon, Firefox et Komodo. Je suis même persuadé que tu aurais plus d’acheteurs Firefox / Komodo que BlueGriffon pour cet éditeur CSS.
On aura l’occasion de parler de tout ça de vive voix la semaine prochaine. Prépare une bassine de tilleul, j’arrive. ;-)
Le futur d'un éditeur "moderne" ne passerait-il pas par l'utilisation de bibliothèques telles que addLib d'Apple ?
Maintenant je ne suis pas le plus à même de parler d'outils comme Nvu/Kompozer/BlueGriffon vu que je n'ai jamais vu comment les utiliser de concert avec des CMS comme Spip !
http://www.macworld.fr/2010/04/08/i...
Fakir > contrairement à Komodo, Nvu/Kompozer/BlueGriffon ne permettent pas d’éditer des templates SPIP, ni la plupart des templates d’autres CMS : ces éditeurs WYSIWYG ne fonctionnent que sur des pages (x)HTML correctement formées, c’est là leur *grosse* limitation — et c’est bien pour ça que je préfère assurer la pérennité du code, plutôt que de tout bazarder pour ajouter des fonctionnalités qui ne résoudront pas le problème essentiel.
Un éditeur WYSIWYG garde tout son intérêt pour l’apprentissage ou pour la rédaction de contenus ; mais en conception web à proprement parler, il faut un éditeur texte. On n’est plus en 1995.
> On n’est plus en 1995.
>
Dans quel sens l'entends tu ?
Pour ce qui me concerne, depuis le début, en 95 justement, 'vi' est mon ami :-)
> Un éditeur WYSIWYG garde tout son intérêt pour l’apprentissage
>
Ca non seulement je veux bien l'admettre, mais c'est certainement vrai, bien qu'ayant adopté une démarche différente (éditeur brut de décoffrage). Je pense avoir ouvert l'éditeur de Netscape 2 une fois et je n'avais pas du trop adhéré il me semble. Plus tard j'avais aussi testé BlueFish un éditeur Gnome ainsi que son équivalent KDE. C'est à ce moment là que les CMS ont eu ma préference. SPIP en particulier. Sauf que pour des raisons qu'ARNO*, l'un de ses développeur/fondateur, avait expliqué en son temps ce logiciel a mis du temps à basculer du HTML au XHTML/CSS.
Il y a toutefois une chose qui m'étonne, vu qu'il me semble que pour toutes sortes de public les CMS ont majoritairement suscité l'adhésion, pourquoi un projet comme BlueGriffon a pu susciter l'intérêt d'un mécène. Autant je comprends que la communauté puisse vouloir maintenir un projet comme Nvu/Kompozer qui peut comme tu le dis avoir un intérêt pédagogique et de soutient à une réalisation Web autant la mise en chantier d'un nouvel éditeur qui ne puisse prendre en compte les principaux CSM ou éditeurs de blog du marché me laisse perplexe. A moins que les fameux addons payants ou gratuits prennent en charge les spécificités de chacun d'entre-eux.
> ou pour la rédaction de contenus
>
Là encore pas trop saisi ce que tu veux dire. Un blog c'est quoi ?
Quoi qu'il en soit félicitation pour votre travail aux 2 équipes.
PS :
Comme je le suggérais sur le blog de Tristan il serait temps que Daniel et toi puissent se retrouver autour d'une bonne table, non pas pour envisager la fusion de vos projets, mais pour essayer de résoudre les incompréhensions qui vous séparent.
Quand j’écris que « on n’est plus en 1995 », j’entends par là qu’à l’époque un éditeur HTML wysiwyg était la solution la plus simple pour mettre du contenu en ligne. En 1995 il n’y avait pas de PHP ni de CSS (ou si peu), et encore moins des plate-formes « blaireau-proof » type MySpace ou FaceBook : un système de publication type Netscape Composer était donc très utile.
Aujourd’hui il serait impensable de faire un site web sans un minimum de pré-processing coté serveur (PHP, Python, Ruby, etc.) ; or, c’est précisément sur ce point qu’un éditeur wysiwyg comme Composer (= Nvu/Kompozer/BlueGriffon) est inutilisable, et qu’un éditeur texte comme Komodo prend tout son sens.
Par « rédaction de contenus » j’entends par là que mon plan secret de domination du monde consiste à fournir des solutions d’édition de texte qui soient centrées sur l’écran, et non sur le papier : présentations en HTML, documentations en XHTML ou eBook, et plus si affinités. Dans cet objectif, un éditeur HTML basique suffit amplement, à condition qu’il soit fiable et maintenu sur le long terme. J’utilise exclusivement Composer depuis 2000 pour tous mes besoins de documentation. ;-)
Pour le reste, Daniel et moi-même allons prendre une paire d’heures pour discuter IRL de BlueGriffon la semaine prochaine. Je ne cherche ni le clash ni à saper BlueGriffon : tout ce qui m’intéresse c’est d’avoir un éditeur HTML fiable et qui soit maintenu sur le long terme. Kompozer et SeaMonkey ont déjà commencé à fusionner, j’aurais évidemment préféré que BlueGriffon nous rejoigne ; dans le cas contraire, on tâchera de voir comment factoriser le boulot au maximum entre les trois projets.