Geckozone

Merci pour ces tests. Il y aura une autre beta demain !
PS: l'ouverture des fichiers *.php fonctionne désormais sous Ubuntu.

beta du jour : http://fabiwan.kenobi.free.fr/HandCoder ... 308-fr.xpi

Le code n'est plus "doublé" si on ouvre un fichier *.php qui ne contient pas de prologue. J'ai pu éditer tous mes fichiers *.php sur mon poste Ubuntu...

Pour les <br> qui s'ajoutent dans les blocs vides, on n'y peut pas grand-chose, c'est inhérent au fonctionnement de Nvu.
J'ai encore fait pas mal de nettoyage de code, ça devrait mieux cohabiter avec NsmConText (du moins avec la version en cours de développement).

Il m'affiche le code source du fichier precedent dans l'onglet source. (fichier php)

Code : Tout sélectionner

Erreur : prologNode has no properties
Fichier source : chrome://handcoder/content/HandCoder.js
Ligne : 790

Code : Tout sélectionner

Erreur : [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsICommandManager.removeCommandObserver]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://handcoder/content/editorOverlay.js :: SetEditMode :: line 544"  data: no]
Fichier source : chrome://handcoder/content/editorOverlay.js
Ligne : 544

Alors que dans l'onglet normal j'ai un tout autre fichier qui s'affiche
D'ailleurs je peux ouvrir le fichier que je veux, j'ai toujours la meme chose dans l'onglet source.
Meme sans document ouvert, j'ai la meme chose dans l'onglet source. Coincé.

Do-IT a écrit :Il m'affiche le code source du fichier precedent dans l'onglet source. (fichier php)
Code : Tout sélectionner
Erreur : prologNode has no properties
Fichier source : chrome://handcoder/content/HandCoder.js
Ligne : 790

La réécriture de code c'est satisfaisant pour l'esprit du développeur, mais c'est dangereux pour les utilisateurs...

J'ai corrigé cette ligne 790 (qui plantait si aucun prologue n'est trouvé) : http://fabiwan.kenobi.free.fr/HandCoder ... 08b-fr.xpi
Et pourtant tout fonctionnait nickel chez moi...

b20060308b-fr.xpi > Ouverture d'un fichier.html qui contient aucune balise. j'ai pas fait expres, j'en avais un en stock.

Code : Tout sélectionner

Erreur : childNode has no properties
Fichier source : chrome://handcoder/content/HandCoder.js
Ligne : 780

Et l'onglet source m'affiche le contenu du fichier precedent.

Je sais on avait dit que les fragments ne devaient pas porter l'extension html

Mais c'est que ca devient de plus en plus dur de trouver quelque chose.
Retour a l'onglet normal

Code : Tout sélectionner

Erreur : [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsICommandManager.removeCommandObserver]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://handcoder/content/editorOverlay.js :: SetEditMode :: line 544"  data: no]
Fichier source : chrome://handcoder/content/editorOverlay.js
Ligne : 544

HandCoder-b20060308c-fr.xpi
J'écris la phrase phrase magique, celle qui fait sortir plein de bugs : ça sent la release.

Do-IT a écrit :b20060308b-fr.xpi > Ouverture d'un fichier.html qui contient aucune balise. j'ai pas fait expres, j'en avais un en stock. [...]
Je sais on avait dit que les fragments ne devaient pas porter l'extension html

Ce bug aurait pu apparaître avec d'autres documents tordus.
Quand tu cliques sur l'onglet "Normal", HandCoder essaye de reformater le code sous une forme utilisable par Nvu, échoue, et plante l'onglet Source pour de bon. Ce genre de chose fait partie des raisons pour lesquelles je préfèrerais avoir une boite de dialogue plutôt que cet onglet...

Du coup, tu m'as donné l'idée d'essayer d'ouvrir des fichiers incongrus avec Nvu + HandCoder :

fichier *.html vide. L'éditeur source de Nvu n'est pas planté (depuis la version c), mais il considère l'onglet courant comme vide : si on ouvre un autre fichier, l'onglet est remplacé, et l'onglet Source donne le code d'une page HTML (complète, mais vide).
fichier *.tpl vide. Similaire, mais on voit un unique <br> dans l'onglet Source (qui a donc été rajouté par Nvu).
fichier *.css. Sélectionner tout, passer en "préformaté"... surprise. L'onglet source n'est pas mal non plus.

Le CSS est un mauvais exemple, il vaudrait mieux que je fasse en sorte qu'il soit ouvert par KaZcadeS ; mais ça pourrait être plus utile pour de petits fichiers texte (*.htaccess, *.rdf, *.js, etc.). Techniquement, utiliser Nvu comme mini éditeur texte, ça ne serait pas bien compliqué.

PS: j'ai failli oublier le bonus ! 8)

Code : Tout sélectionner

<!-- #BeginDate dd/MM/yyyy hh:mm:ss --> 03/03/2006 12:51:50 <!-- #EndDate -->

Ca n'a pas la prétention d'être stable, il faudrait un item dans le menu "Insertion", etc, donc ça restera en fonctionnalité "cachée" (pas la peine de signaler les bugs, ça n'est que le tout début). Ca reste utilisable pour qui sait coller un bout de texte dans l'onglet Source.

Kaze a écrit :HandCoder-b20060308c-fr.xpi

Mauvais lien. (corrigé)
HandCoder-b20060308c-fr.xpi > Fermeture d'un nouveau document (vide ou pas vide)

Code : Tout sélectionner

KazIO: could not get path from ~about:strictblank.html

Le bonus marche pas chez moi, faut un pré-requis ?

Mais ?! Nvu essaie d'ouvrir betement tous les types de fichier sans se poser de question ? (sans nsm)

Do-IT a écrit :Mauvais lien.

Ca, au moins, c'est vite corrigé !

Do-IT a écrit :HandCoder-b20060308c-fr.xpi > Fermeture d'un nouveau document (vide ou pas vide)
Code : Tout sélectionner
KazIO: could not get path from ~about:strictblank.html

Rien de grave (ça n'est qu'un message, pas une erreur). Je corrigerai ça à l'occasion (ou je masquerai le message).

Do-IT a écrit :Mais ?! Nvu essaie d'ouvrir betement tous les types de fichier sans se poser de question ? (sans nsm)

Oui. Essaye sans HandCoder, c'est pareil.

(du moins je crois, je n'ai pas essayé depuis longtemps)
Le sort de HandCoder reste lié à celui de NsmConText pour le filtrage des fichiers selon leur extension.

Do-IT a écrit :Le bonus marche pas chez moi, faut un pré-requis ?

Euh, faut virer les espaces :

Code : Tout sélectionner

<!--#BeginDate dd/MM/yyyy hh:mm:ss--> 03/03/2006 12:51:50 <!--#EndDate-->

Voilà pourquoi ça restera en fonctionnalité cachée pour l'instant...

Essaie d'ouverture de ce fragment php => Il se passe rien

Code : Tout sélectionner

<?php if ($condition) { die('</body></html>'); } ?>

La meme chose dans un document html complet fonctionne.

Chez moi les fragments php contiennent que du php (rien en dehors de <?php ... ?>). C'est parfois indispensable dans le cas de generation d'image ou d'upload de fichier (qui genere un header)
Editer ces fragments avec nvu (non indenté) n'a aucun sens. L'editeur externe est obligatoire donc nsm aussi (depuis la disparition de la fenetre d'alerte à l'ouverture).
Et si j'utilise un editeur externe pour mes fragments php sans ouvrir dans nvu. Qu'en est-il de l'indentation ? Tidy sait faire ca ? Est-ce que j'en ai besoin ? Ou je fais mon indentation moi meme ?

Le bonus fonctionne.

Pour les fichiers temporaire ~fichier.php.html ou autre MFCE.tmp etc
Je me demande quel est le degré de problème de sécurité que ca génére. Sachant que le contenu d'un fichier php n'est pas censé etre visible sur le net. Par exemple si quelqu'un travail directement sur un serveur web ou en cas de synchronisation. Je suis pas concerné, je me pose juste la question.
C'est également perturbant de voir le fichier temporaire quand on fait un enregistrer sous.
Faut-il cacher le fichier temporaire ? Le mettre ailleurs ?

Do-IT a écrit :Essaie d'ouverture de ce fragment php => Il se passe rien
Code : Tout sélectionner
<?php if ($condition) { die('</body></html>'); } ?>
La meme chose dans un document html complet fonctionne.

A corriger. Ce type de fichier devrait être ouvert par l'éditeur texte.

Do-IT a écrit :Chez moi les fragments php contiennent que du php (rien en dehors de <?php ... ?>). C'est parfois indispensable dans le cas de generation d'image ou d'upload de fichier (qui genere un header)
Editer ces fragments avec nvu (non indenté) n'a aucun sens. L'editeur externe est obligatoire donc nsm aussi (depuis la disparition de la fenetre d'alerte à l'ouverture).

Je ne suis pas sûr que cette fenêtre d'alerte soit une grosse perte (elle est toujours dans le code, mais n'est plus utilisée), car le choix est simple :

document HTML (avec l'extension *.html) Nvu (!)
squelette PHP avec DOCTYPE (et prologue PHP) Nvu (+ fichier temporaire)
fragment 100% HTML Nvu (+ fichier temporaire)
fragment 100% PHP éditeur texte (du moins ça devrait)

Le cas un peu limite, c'est le fragment qui contient du HTML et du PHP. Dans certains cas il peut être utile de les ouvrir avec Nvu, mais bon, ça devient de l'acharnement. Pour simplifier, je pourrais faire en sorte que les fragments contenant du PHP, ainsi que tous les fichiers qui commencent par <? et finissent par ?>, soient toujours ouverts avec l'éditeur texte.

Tous ces fichiers appartiennent au type "Scripts serveur" de NsmConText, sauf le premier évidemment. C'est la catégorie un peu mixte, dont les fichiers s'éditent parfois avec Nvu, parfois avec l'éditeur texte, mais qui sont visualisables dans un navigateur.
Quand on double-clique sur un fichier, NsmConText l'ouvre avec l'application associée, ou avec l'application par défaut du système si le fichier n'appartient à aucune des catégories de NsmConText.

Pour pouvoir utiliser HandCoder sans NsmConText, il faudrait donc pouvoir spécifier dans les préfs les filtres de fichier pour les catégories "Documents HTML", "Scripts serveur" et "Texte". Il faudrait également que ces prefs soient communes avec NsmConText.

Do-IT a écrit :Et si j'utilise un editeur externe pour mes fragments php sans ouvrir dans nvu. Qu'en est-il de l'indentation ? Tidy sait faire ca ? Est-ce que j'en ai besoin ? Ou je fais mon indentation moi meme ?

L'indentation d'un fragment PHP peut être faite par aStyle (le Tidy du langage C), que tu peux utiliser depuis ton éditeur texte.
Mais, AMHA, ça n'a d'intérêt que pour des gros fichiers de code, et principalement quand on travaille à plusieurs sur un même projet : ça permet de standardiser la présentation du code d'un développeur à l'autre. C'est sympa mais pas indispensable ; je l'ai activé dans mon Visual Studio, je m'en passe sous SciTE.

Do-IT a écrit :Pour les fichiers temporaire ~fichier.php.html ou autre MFCE.tmp etc
Je me demande quel est le degré de problème de sécurité que ca génére. Sachant que le contenu d'un fichier php n'est pas censé etre visible sur le net.

Il n'y a aucun problème de sécurité, puisque le fichier temporaire est toujours créé sur le disque dur, jamais sur le site. De toutes façons HandCoder ne fonctionne pas encore sur les fichiers distants ; pour ça il aura besoin de NsmConText 0.4.x ou 0.5.x...

Do-IT a écrit :C'est également perturbant de voir le fichier temporaire quand on fait un enregistrer sous.
Faut-il cacher le fichier temporaire ? Le mettre ailleurs ?

DW et Word font des fichiers temporaires et personne ne s'en plaint !

Plus sérieusement, je trouve ça gênant aussi. NsmConText masque les fichiers temporaires dans le gestionnaire de sites, mais ce n'est pas suffisant (ne serait-ce que pour ceux qui ne l'installent pas !). Je ne sais pas si on peut créer un fichier caché (au sens de l'OS) depuis Nvu, je vais regarder ça.
Mettre les fichiers temporaires ailleurs, j'ai essayé, mais je n'ai pas réussi à le faire sans perdre les liens relatifs (styles, images, etc).

Do-IT a écrit :Le bonus fonctionne.

Je pensais que ça plairait à galad mais finalement elle a l'air motivée pour faire du PHP

Kaze a écrit :fragment 100% PHP éditeur texte (du moins ça devrait)
... le fragment qui contient du HTML et du PHP. ... ça devient de l'acharnement. ... les fragments contenant du PHP, ainsi que tous les fichiers qui commencent par <? et finissent par ?>, soient toujours ouverts avec l'éditeur texte.

La finalité de l'extension n'est-elle pas de tout editer dans nvu. Tu avais prevu quoi a se sujet à tres long terme ? Disparition définitive de l'editeur externe ?

La fenetre d'alert idem, je pourrai m'en passer. Quoi qu'une option sera la solution ?
Mes fragment 100% php s'affiche bien dans nvu (sauf l'indentation detruite). Si je veux l'editer dans un editeur externe je clic sur le bouton editeur.
La seul chose qui pose probleme c'est le cas du die('</body></html>'); là je ne sais meme pas si c'est une erreur de conception de ma part. Il existe d'autre facon d'arriver a ces fins sans ce code. Mais c'est pas une raison, nvu devrait faire quelque chose quand je lui dit de l'ouvrir.

Kaze a écrit :Il n'y a aucun problème de sécurité, puisque le fichier temporaire est toujours créé sur le disque dur

Là je suis pas d'accord. Si le dossier local et le meme que le dossier du serveur il y a un probleme potentiel. Idem pour une synchro externe à nvu. C'est un probleme potentiel.

Do-IT a écrit :La finalité de l'extension n'est-elle pas de tout editer dans nvu. Tu avais prevu quoi a se sujet à tres long terme ? Disparition définitive de l'editeur externe ?

Oui, ainsi que le rachat de Krosoft et le recrutement de Kazettes douces et dévouées.

A long terme je pense qu'il faut intégrer un vrai éditeur texte dans Nvu, dans un dock.
D'ici là, un éditeur texte externe me parait indispensable...

Do-IT a écrit :La seul chose qui pose probleme c'est le cas du die('</body></html>')

Ce bout de texte n'est pas vu comme un fragment car il contient les chaines </body> et </html>. Il n'est pas vu comme une page HTML car il manque tout le reste.
Nvu ne pourra pas tout éditer sans risque de perdre des données. Du coup, la solution serait peut-être bien d'utiliser Nvu comme éditeur texte pour certains fichiers...

Do-IT a écrit :
Kaze a écrit :Il n'y a aucun problème de sécurité, puisque le fichier temporaire est toujours créé sur le disque dur
Là je suis pas d'accord. Si le dossier local et le meme que le dossier du serveur il y a un probleme potentiel. Idem pour une synchro externe à nvu. C'est un probleme potentiel.

J'avais pas pensé à ça !

Pour la synchro externe, les logiciels de synchro permettent d'ignorer les fichiers temporaires, il suffit de le paramétrer.

Ces fichiers temporaire doivent porter une extension *.html pour pouvoir être édités sous Ubuntu. Il faudrait donc les créer dans un dossier temporaire... à suivre.

Mandriva2006 (user) > nvu (en) > HandCoder-b20060308c-fr.xpi

Kaze a écrit :Il faudrait donc les créer dans un dossier temporaire... à suivre.

Ou cacher les fichiers (le plus simple ?). Ou ne rien faire (Probabilité quasi nulle ?)

Pour la 0.3.2, je ne vais rien modifier, uniquement faire une version multilingue (si j'y arrive) de la version "c".
Il restera donc quelques bugs, mais je crois qu'en l'état, elle sera utile à pas mal de monde. Il y aura d'autres beta pour améliorer tout ça, et peut-être même essayer d'inclure un mode "édition texte" dans Nvu.

Do-IT a écrit :Mandriva2006 (user) > nvu (en) > HandCoder-b20060308c-fr.xpi

La façon dont Nvu traite les locales est vraiment pénible.
Pour NsmConText, il y a un fichier *.xpi par langue.
Pour KaZcadeS j'ai réussi à faire une extension multilingue, mais elle plante (avec ce genre d'erreur) quand on l'installe sur un Nvu dont la langue n'est pas contenue dans le *.xpi
Pour HandCoder, j'ai réussi à garder les inconvénients des deux systèmes.

Si quelqu'un peut m'expliquer comment fonctionnent les locales dans Nvu, merci d'avance.

D'ici là tu peux installer un Nvu français, ou tester avec cette version anglaise (je crois que c'est la "b") : http://fabiwan.kenobi.free.fr/HandCoder ... 308-en.xpi

Do-IT a écrit :
Kaze a écrit :Il faudrait donc les créer dans un dossier temporaire... à suivre.
Ou cacher les fichiers (le plus simple ?). Ou ne rien faire (Probabilité quasi nulle ?)

Cacher les fichiers ne résoudrait pas le problème de sécurité, mais serait plus joli à l'affichage.

Geckozone

HandCoder : extension Nvu pour Tidy et PHP