Bonjour,
J'étais samedi aux Journées Du Logiciel Libre 2004 à Lyon
(http://www.aldil.org/agenda/journees/2004/).
Il y avait le créateur de Nvu, Daniel Glazman.
Il nous a fait une présentation de Nvu dont est sorti des infos stratégiques
intéressantes :
- Nvu est adopté de plus en plus en université et par des grands groupe en
lieu et place de DreamWeaver ! (dernièrement, un grand groupe du nord de
l'europe abandonant 4000 licences de Dreamweaver pour Nvu)
- Nvu est en pour-parler avec la Mozilla foundation pour être intégré en
standard comme éditeur (X)HTML de Mozilla
- Un éditeur Nvu XML est en préparation
- des extensions par plugins .xpi (à la FireFox) seront rapidement possibles
(version 0.7)
- Tant que les boucles SPIP ne respecteront une grammaire XML (et non SGML
comme c'est le cas actuellement), Nvu ne sera pas capable d'ouvrir un
squelette SPIP sans le détruire !
Donc, à mon humble avis (pour ce qu'il vaut), creuser l'idée d'Emmanuel de
mettre en place une grammaire de boucle SPIP XML compliant serait à terme un
choix stratégique gagnant pour contribuer à étendre l'usage de SPIP.
De plus Nvu est "embedable" et pourrait permettre de faire un SPIPEditNvu
qui serait d'emblé cross-platform!
Je ne dis pas non plus qu'il faut foncer tête baissée dans cette direction.
Mais il y a un train que nous pourrions prendre...
- Tant que les boucles SPIP ne respecteront une grammaire XML (et non SGML
comme c'est le cas actuellement), Nvu ne sera pas capable d'ouvrir un
squelette SPIP sans le détruire !
La grammaire actuelle n'est ni XML ni SGML, elle est ad-hoc 
Donc, à mon humble avis (pour ce qu'il vaut), creuser l'idée d'Emmanuel de
mettre en place une grammaire de boucle SPIP XML compliant serait à terme un
choix stratégique gagnant
Gagnant ?? La question est toujours de trouver une grammaire XML qui
soit aussi simple et concise que la grammaire actuelle. J'ai la vague
impression que ce sera assez difficile...
L'autre possibilité, à mon avis la plus satisfaisante, est que Nvu soit
amélioré afin d'accepter les fichiers non-XML (au moins en conjonction
avec le plug-in adéquat qui se chargerait de la médiation : je ne dis
pas qu'il doit les accepter en natif).
Amicalement
Antoine.
Antoine wrote:
- Tant que les boucles SPIP ne respecteront une grammaire XML (et
non SGML comme c'est le cas actuellement), Nvu ne sera pas capable
d'ouvrir un squelette SPIP sans le détruire !
La grammaire actuelle n'est ni XML ni SGML, elle est ad-hoc
Donc, à mon humble avis (pour ce qu'il vaut), creuser l'idée
d'Emmanuel de mettre en place une grammaire de boucle SPIP XML
compliant serait à terme un choix stratégique gagnant
Gagnant ?? La question est toujours de trouver une grammaire XML qui
soit aussi simple et concise que la grammaire actuelle. J'ai la vague
impression que ce sera assez difficile...
Moi aussi.
Par contre, il est peut-être envisageable de disposer de 2 grammaire :
l'actuelle et une XML et bien sûr d'un outil de traduction de squelette de
l'une vers l'autre et réciproquement.
L'autre possibilité, à mon avis la plus satisfaisante, est que Nvu
soit amélioré afin d'accepter les fichiers non-XML (au moins en
conjonction avec le plug-in adéquat qui se chargerait de la médiation
: je ne dis pas qu'il doit les accepter en natif).
J'en ai parlé en tête à tête avec lui (Daniel).
Nvu fait un parsing du DOM pour "reconstruire" un fichier HTML valide (et
fait cela au chargement de la page).
Daniel refuse de travailler avec une DTD non conforme aux standards.
Je ne me suis pas penché sur son travail. Lui-même dit qu'il faut 6 mois à
pleins temps pour comprendre l'API d'édition HTML de Mozilla!
Le but de mon post, c'est juste que nous gardions un oeil sur Nvu et
puissions en discuter ici de temps en temps.
Nvu est d'autre part loin d'être stabilisé. Donc, il est sans doute sage
d'attendre un peu.
J'ai fait ce compte-rendu ici tant que c'était frais dans ma mémoire.
Amicalement
Amicalement aussi
Antoine wrote:
- Tant que les boucles SPIP ne respecteront une grammaire XML (et non SGML
comme c'est le cas actuellement), Nvu ne sera pas capable d'ouvrir un
squelette SPIP sans le détruire !
La grammaire actuelle n'est ni XML ni SGML, elle est ad-hoc
Donc, à mon humble avis (pour ce qu'il vaut), creuser l'idée d'Emmanuel de
mettre en place une grammaire de boucle SPIP XML compliant serait à terme un
choix stratégique gagnant
Gagnant ?? La question est toujours de trouver une grammaire XML qui
soit aussi simple et concise que la grammaire actuelle. J'ai la vague
impression que ce sera assez difficile...
L'autre possibilité, à mon avis la plus satisfaisante, est que Nvu soit
amélioré afin d'accepter les fichiers non-XML (au moins en conjonction
avec le plug-in adéquat qui se chargerait de la médiation : je ne dis
pas qu'il doit les accepter en natif).
Amicalement
Antoine.
Hello,
je suis bien d'accord, je ne vois pas trop comment un editeur de contenue web, de nos jours, peut se passer d'un suport au minimum de sgml?
Peu être dans 10ans, tous les sites du monde seront passé à un format pure xml, mais c'est loin d'etre le cas. Si je veux prendre un vieux site que j''ai fait avec NVu (idependemment de spip), s'il est pas en xml, il sera "detruit"... c'est un peu dur non?
D'un autre cote, ayant été moi même bidouillé dans les regexp de parsings des balises spip, je suis tout à fait d'accord qu'une notation moins ad-hoc serait plus utile (entendre plus étendable). mais apporterai un gros probleme de backward compatibility.
Pierre
Antoine wrote:
- Tant que les boucles SPIP ne respecteront une grammaire XML (et non SGML
comme c'est le cas actuellement), Nvu ne sera pas capable d'ouvrir un
squelette SPIP sans le détruire !
La grammaire actuelle n'est ni XML ni SGML, elle est ad-hoc
Donc, à mon humble avis (pour ce qu'il vaut), creuser l'idée d'Emmanuel de
mettre en place une grammaire de boucle SPIP XML compliant serait à terme un
choix stratégique gagnant
Gagnant ?? La question est toujours de trouver une grammaire XML qui
soit aussi simple et concise que la grammaire actuelle. J'ai la vague
impression que ce sera assez difficile...
bah, il n'y a pas grand chose qui ne soit pas valide, juste les <img150|right> qui deviendrait <img id="150" align="right"/> trop proche du HTML pour être pertinant. Il faudrait autre chose que < et > pour englober.
Aprés pour les boucles, il faudrait un namespace <spip:boucle ></spip:boucle>
Ca perds pas mal du charme originel, et ça ressemble méchament à du JSP.
D'un autre coté, parser du XML valide, c'est du bonheur point de vue code.
Je penses que le soucis est plus dans les raccourcis typos où l'utilisateur doit être le moins martyrisé possible. Pour les squelettes, il faut deja faire du XHTML propre, ce n'est pas quelques balises permissives à l'interieur qui vont soulager le travail de quiconque.
Encore un truc pour la 1.9, ça.
M.
PS : Juste une petite requète, serait-ce possible qu'un simple "reply" suffise pour répondre à la liste plutot qu'un "reply-all" et effaçage de l'auteur à qui on réponds?
> L'autre possibilité, à mon avis la plus satisfaisante, est que Nvu
> soit amélioré afin d'accepter les fichiers non-XML (au moins en
> conjonction avec le plug-in adéquat qui se chargerait de la médiation
> : je ne dis pas qu'il doit les accepter en natif).
J'en ai parlé en tête à tête avec lui (Daniel).
Nvu fait un parsing du DOM pour "reconstruire" un fichier HTML valide (et
fait cela au chargement de la page).
Oui, j'avais compris
Mais si le système de plug-in est suffisamment souple, il devrait être
possible :
- de faire une pré-passe du plug-in au chargement qui traduirait les
boucles en XML "conforme"
- de faire une post-passe à la sauvegarde qui retraduirait le "XML
interne" en boucles SPIP : l'enjeu étant que le webmestre puisse
retravailler le fichier à la main sans se retrouver face à un "SPIP-XML"
incompréhensible !
Je ne sais pas en quel langage est codé Nvu (C++ ?) mais il devrait être
possible de faire en sorte que le plug-in présente un stream au moteur
interne. Par défaut le stream serait le FILE* du fichier, mais le
plug-in SPIP présenterait le stream sur une chaîne déjà traitée
(stringstream en C++ si je me souviens bien).
Daniel refuse de travailler avec une DTD non conforme aux standards.
Le mot ayatollah va fuser.
(ça existe encore les DTD ? je croyais qu'on était passé aux schémas)
Je ne me suis pas penché sur son travail. Lui-même dit qu'il faut 6 mois à
pleins temps pour comprendre l'API d'édition HTML de Mozilla!
Ah ben super... On sent que c'est bien foutu. Une vraie rente de
situation, un peu comme le code interne de SPIP 
Troll à part, il est reconnu que si Apple a pris KHTML (le moteur de
Konqueror) plutôt que Gecko (le moteur de Mozilla) pour son navigateur
Safari, c'est que KHTML est dix fois plus petit et plus facilement
récupérable dans un programme externe.
Le but de mon post, c'est juste que nous gardions un oeil sur Nvu et
puissions en discuter ici de temps en temps.
La liste la plus appropriée serait peut-être spip-lab, ça éviterait
d'encombrer celle-ci avec des discussions "prospectives".
Amicalement
Antoine.
Antoine wrote:
L'autre possibilité, à mon avis la plus satisfaisante, est que Nvu
soit amélioré afin d'accepter les fichiers non-XML (au moins en
conjonction avec le plug-in adéquat qui se chargerait de la
médiation
je ne dis pas qu'il doit les accepter en natif).
J'en ai parlé en tête à tête avec lui (Daniel).
Nvu fait un parsing du DOM pour "reconstruire" un fichier HTML
valide (et fait cela au chargement de la page).
Oui, j'avais compris
Mais si le système de plug-in est suffisamment souple, il devrait être
possible :
- de faire une pré-passe du plug-in au chargement qui traduirait les
boucles en XML "conforme"
- de faire une post-passe à la sauvegarde qui retraduirait le "XML
interne" en boucles SPIP : l'enjeu étant que le webmestre puisse
retravailler le fichier à la main sans se retrouver face à un
"SPIP-XML" incompréhensible !
Sans doute.
Je ne sais pas en quel langage est codé Nvu (C++ ?)
20% de C++
80% de XUL (javascript pour piloter l'interface utilisateur)
A terme, ça pourrait être 100% de XUL !
Daniel refuse de travailler avec une DTD non conforme aux standards.
Le mot ayatollah va fuser.
Disons tétu, mais comme disait Tristan Nitot (www.standblog.org) : «c'est
comme un poulpe, il faut taper dessus pour l'attendrir»
(ça existe encore les DTD ? je croyais qu'on était passé aux schémas)
Je ne me suis pas penché sur son travail. Lui-même dit qu'il faut 6
mois à pleins temps pour comprendre l'API d'édition HTML de Mozilla!
Ah ben super... On sent que c'est bien foutu. Une vraie rente de
situation, un peu comme le code interne de SPIP
D'après Daniel, c'est que c'est *beaucoup* plus puissant et bati dans la
volonté d'implémenter les standards du W3C.
Troll à part, il est reconnu que si Apple a pris KHTML (le moteur de
Konqueror) plutôt que Gecko (le moteur de Mozilla) pour son navigateur
Safari, c'est que KHTML est dix fois plus petit et plus facilement
récupérable dans un programme externe.
Tristan et Daniel ont avancé samedi une autre hypothèse : le moteur de KHTML
était aussi plus exposé à ne pas pouvoir résister à un "coup d'état".
En effet, on peut dire que Apple a pris le code source de KHTML, a fait 6
mois travail et a reversé 6 mois de diff a la commaunauté sans en avoir
parlé à celle-ci avec des choix abérants (tiens, ça me rappelle quelque
chose...). Ça n'aurait pas été possible avec Gecko.
Le but de mon post, c'est juste que nous gardions un oeil sur Nvu et
puissions en discuter ici de temps en temps.
La liste la plus appropriée serait peut-être spip-lab, ça éviterait
d'encombrer celle-ci avec des discussions "prospectives".
Quand est-ce que la liste spip-lab passe sur gmane pour y avoir accès avec
un client de news ?
Je peut aussi faire une page sur le wiki du lab. Non ?
(merci pour les infos sur KHTML/Gecko)
Quand est-ce que la liste spip-lab passe sur gmane pour y avoir accès avec
un client de news ?
Je ne sais pas comment on fait. Si ça se trouve, tu peux même faire la
demande à gmane toi-même.
Je peut aussi faire une page sur le wiki du lab. Non ?
Oui, bien évidemment.
a+
Antoine.
Jacques PYRAT a écrit :
Bonjour,
J'étais samedi aux Journées Du Logiciel Libre 2004 à Lyon
(http://www.aldil.org/agenda/journees/2004/).
Il y avait le créateur de Nvu, Daniel Glazman.
Dommage que Nvu ne gère pas (encore) les fichiers CSS (ou alors je me suis mal débrouillé) car à chaque fois que je veux ouvrir un fichier CSS je me fais dégager par un phrase du style ce n'est pas un fichier html valide... :-/
Pour un éditeur web, je trouve cela dommage... 
Nicolas
Nicolas Steinmetz wrote:
Jacques PYRAT a écrit :
Bonjour,
J'étais samedi aux Journées Du Logiciel Libre 2004 à Lyon
(http://www.aldil.org/agenda/journees/2004/).
Il y avait le créateur de Nvu, Daniel Glazman.
Dommage que Nvu ne gère pas (encore) les fichiers CSS (ou alors je me
suis mal débrouillé) car à chaque fois que je veux ouvrir un fichier
CSS je me fais dégager par un phrase du style ce n'est pas un fichier
html valide... :-/
D'après la démo de samedi, il faut ouvrir un fichier HTML qui link un
fichier CSS.
Et là, tu pourras ouvrir le CSS associé.
Jacques PYRAT a écrit :
> D'après la démo de samedi, il faut ouvrir un fichier HTML qui link un
fichier CSS.
Et là, tu pourras ouvrir le CSS associé.
Mouarf, c'est tout sauf intuitif comme comportement...
En tous cas, merci de l'astuce
Nicolas
Salut,
Par contre, il est peut-être envisageable de disposer de 2 grammaire :
l'actuelle et une XML et bien sûr d'un outil de traduction de squelette de
l'une vers l'autre et réciproquement.
2 grammaires, ce n'est pas très serieux tout de même, car un beau
jour on mélange tout et a chaque boucle il te faut alors determiner quel
chemin d'analyseur lexical prendre. l'ancien, le nouveau, et "badaboom".
(les shakers c'est toujours ragoutant à nettoyer )
non ?
Si transformation de grammaire il doit y avoir c'est plutôt aux
développeurs de fournir un jeu de scripts permettant la refonte d'une
ancienne grammaire en une nouvelle plutot que de glisser les 2
fonctionnalités. A faire trop de branchements on perd de nombreux
cycles. Ainsi permettre à tout utilisateur une bascule efficace et sans
bavures.
IMHO c'est à NVU de s'adapter pour ne pas détruire ce qui existe
déja, c'est lui l'éditeur de sites. non ? NVU n'est qu'un outil parmis
tant d'autres... First there was Einz, latter Zwei, then .. eeeeeeeemacs ?
VImproved r0x
bonne soirée,
/lex