Je viens de jeter un œil à HandCoder, c’est clair et net : il faut réécrire cette extension assez lourdement pour KompoZer 0.8. Je suis même assez surpris que HandCoder 0.3.x ait pu fonctionner jusque-là sur KompoZer 0.8.
Dans la version courante de HandCoder (0.3.x), je me trimballe déjà tout un tas de code moisi pour assurer un semblant de compatibilité avec Nvu ; pas question d’en rajouter une couche pour avoir une même extension installable sous KpZ 0.7 et 0.8.
electrophil a écrit :A une époque tu avais parlé d'intégrer directement Handcodeur à Kompozer.
Cela serait peut être mieux que d'avoir des versions d'extensions spécifiques.
Ce n’est pas si simple. Si on fait le détail des fonctionnalités de HandCoder, on a grosso modo :
- les corrections de bugs Nvu
- une librairie, partagée avec NsmConText, pour lancer des applications externes
- l’ajout d’un bouton et d’un raccourci clavier pour éditer le document courant dans un éditeur externe
- l’alerte « fichier modifié », qui apparaît quand un document de KompoZer est modifié par une application externe
- la possibilité de lancer le nettoyeur de balises avant sauvegarde
- la possibilité de reformatter le code avec Tidy avant sauvegarde
- la possibilité d’ouvrir et de sauvegarder des fragments de code (x)html, i.e. des documents HTML bien formés mais sans nœud <html>, <head> ni <body>
- un meilleur support PHP (notamment sous Linux), voire ASP/JSP/Ruby (i.e. les balises <%
%>)
Les points 1 et 2 sont assurés par KompoZer 0.8, mais entrent en conflit avec le code de HandCoder.
Les points 3 et 4 me paraissent fiables, à ceci près que ça ne fonctionne que sur des documents édités localement (sur le disque dur). Vu que je vais bosser sur le support FTP pour l’alpha5, les fichiers distants devraient être supportés à relativement court terme.
Les points 5 et 6 constituent l’aspect le plus important, mais je ne les considère pas encore comme fiables, notamment parce que la liaison avec Tidy est capricieuse et dépend fortement de la version de Tidy utilisée. Par ailleurs, ça n’est pas supporté sur MacOS X.
Les points 7 et 8, en revanche, sont encore expérimentaux. À eux seuls, ils me contraignent à conserver une extension séparée : pas question de faire des mises à jour de KompoZer à chaque fois qu’il faudra faire évoluer ces points-là.
Conclusion : il faudra garder HandCoder, mais il faudra le réécrire.
Ce qui semblerait raisonnable à court terme, c’est d’intégrer les points 3 et 4 dans KompoZer 0.8 (alpha5) et de faire une version 0.4 de HandCoder qui ne fonctionnerait que sur KompoZer 0.8, et se focaliserait sur les points 5 à 8.
Pour ce qui est de Tidy, ainsi que je l’ai signalé dans
un autre sujet :
J’ai deux options pour remettre le code au carré :
- intégrer Tidy dans KompoZer : indentation nickel-chrome, tout plein d’options de mise en forme, mais risque de dénaturer le code source (voire de perdre des éléments au passage)
- bosser sur le sérialiseur XHTML de Gecko : pas d’options de mise en forme mais on est assuré de la fidélité du code (x)HTML. Laurent Jouanneau a proposé un patch long comme le bras pour ça, il faut que je voie si je peux l’implémenter et si ça reste compatible avec les spécificités de KompoZer (PHP notamment)
Dans les deux cas, ça suppose pas mal de boulot, mais je sais que c’est faisable. Par contre, ce n’est pas un objectif prioritaire pour la branche 0.8 de KompoZer : on va déjà résoudre les bugs du moment avant de se poser la question.
Le patch de Laurent n’est applicable que sur Gecko 1.9, or KompoZer 0.8 est encore en Gecko 1.8.
L’intégration de Tidy dans KompoZer serait donc la seule façon de répondre correctement au besoin pour la branche 0.8, mais si ça me prend plus de temps que de porter KompoZer sur Gecko 1.9 ça n’est pas pertinent, matériellement parlant. Il faut que j’évalue le boulot que représentent ces deux options respectives
Ymai a écrit :Sans aucune idée de vouloir mettre la pression, c'est vraiment LE truc que j'attends.
Je fais partie des gens qui considèrent que KompoZer n’a aucun intérêt sans Tidy. Je considère donc HandCoder comme indispensable, mais la priorité absolue c’est d’abord de débugger KompoZer 0.8.
Je pense que la solution proposée ci-dessus (points 3 et 4 dans KompoZer 0.8, points 5 à 8 dans HandCoder 0.4) est l’option la plus raisonnable à court terme. Maintenant que KompoZer 0.8 devient utilisable, il faudra bien avoir un HandCoder adapté rapidement.
electrophil a écrit :Bon, c'est hors sujet: comment fait-on et où peut-on se renseigner sur une participation à la traduction ou à la mise à jour des pack de langue?
On me contacte.

Cédric et Giuseppe finissent de mettre en place certains outils de communication (serveur mailing-lists et/ou newsgroup), et il paraît raisonnable d’attendre que tout soit en place avant de lancer l’assaut.
Pour le français, Cédric est déjà en charge du pack de langue, et je préfère qu’il le reste : ça nous permet d’utiliser les mêmes outils que les équipes de localisation, et donc de s’assurer que ces outils fonctionnent correctement.