Geckozone

Kazé a écrit :un lâche a écrit:

Bizarre, je croyais m'être logger

Comme je ne suis pas rancunier

, je vais réinstaller en modifiant les options, et on verra bien ce qu'on verra

J'ai choisi le dernier item: mauvaise pioche: la barre de titre de Nvu s'affole: clignotement ininterrompu du titre comme si je cliquais 1012 fois sur accepter les modifications: seul avantage: je peux aller faire la sieste
Si c'est le 1er item qui est coché, tout est calme, ouf. Enfin quelque chose de normal

Console JS:

Code : Tout sélectionner

Erreur : GetCurrentEditor() has no properties
Fichier source : chrome://editor/content/editorUtilities.js
Ligne : 1233
Erreur : GetCurrentEditor() has no properties
Fichier source : chrome://htmlheader/content/toolbarButtons.js
Ligne : 122
Erreur : e has no properties
Fichier source : chrome://editor/content/bindings/tabeditor.xml
Ligne : 444

Evidemment j'ai ces 3 messages 1012 fois

Conclusion?: incompatibilité avec d'autres extensions,non?

chinon37 a écrit :la barre de titre de Nvu s'affole: clignotement ininterrompu du titre comme si je cliquais 1012 fois sur accepter les modifications: seul avantage: je peux aller faire la sieste
Si c'est le 1er item qui est coché, tout est calme, ouf. Enfin quelque chose de normal

Idem. Mais de là a dire que c'est normal.
Donc ca me le fait avec un fichier php, avec un fragment html, mais pas avec un fichier html. Un frag php ouvre l'editeur externe (ok).

Pour le doctype et le charset j'essaierai de voir ca se soir.

Do-IT a écrit :Mais de là a dire que c'est normal.

le normal était uniquement pour la réaction avec 1er item coché

Précision: mes constats sont sur fichier .php... et le seul moyen d'arrêter le clignotement est de quitter le fichier...

Do-IT a écrit :Donc ca me le fait avec un fichier php, avec un fragment html, mais pas avec un fichier html.

Woh p**** ! Ayé je l'ai vu.

J'étais tellement focalisé sur ces question de doctype et d'encodage que j'ai pas pensé à tester avec des fichiers non-html...

EDIT: avec un fichier HTML, ça ne fonctionne pas bien non plus :
ouvrir un document html > modifier > sauvegarder > mettre une autre fenêtre au premier plan > retour à Nvu > fenêtre maudite.
Il va falloir revenir à l'ancienne méthode. Dommage.

chinon37 a écrit :Evidemment j'ai ces 3 messages 1012 fois
Conclusion?: incompatibilité avec d'autres extensions,non?

Euh, non, vu les adresses chrome, le premier et le troisième message indiquent plutôt une incompatibilité avec Nvu...

Do-IT a écrit :Pour le doctype et le charset j'essaierai de voir ca se soir.

Merci d'avance

Le retour du cliqueur fou. Bon alors pour l'échauffement

Code : Tout sélectionner

Erreur : hcLaunchURI is not defined

quand on clic sur les 4 liens localisation de à propos.

Un truc qui me turlupine : Lancer le nettoyeur de balise a chaque sauvegarde, tu parles de tidy ? (Dans ce cas il vaut mieux mettre lancer tidy a chaque...)
Ou du nettoyage des url absolu en relatif et des codes couleurs. (Dans ce cas il vaut mieux le séparer de tidy).

HandCoder 0.3.3rc4

correction de la détection des fichiers modifiés
ajout de la DTD pour le HTML 4.01 Transitional
correction du clic sur les liens dans l'onglet "A propos"

Je l'ai testée sous Windaube XP mais bon...

Do-IT a écrit :Un truc qui me turlupine : Lancer le nettoyeur de balise a chaque sauvegarde, tu parles de tidy ? (Dans ce cas il vaut mieux mettre lancer tidy a chaque...)
Ou du nettoyage des url absolu en relatif et des codes couleurs. (Dans ce cas il vaut mieux le séparer de tidy).

Il s'agit bien de lancer le nettoyeur de balise à chaque sauvegarde (et avant Tidy).
Le nettoyeur de balises ne corrige pas les codes couleur : c'est impossible de passer les codes couleurs en héxa dans les styles en ligne, et dans les feuilles de style, c'est KaZcadeS qui s'en charge.

A terme, il faudrait inclure Tidy dans le nettoyeur de balises, en ajoutant :

des options "en clair" : indentation, line-wrap, ... (quitte à ne pas implémenter toutes les options de Tidy)
une case "remplacer les styles en ligne par une feuille de style"
une section pour convertir le document en html / xhtml / strict / loose

Idéalement, cet onglet "Tidy" disparaitrait complètement. Il suffirait d'inclure TidyLib dans HandCoder (cf. la version 0.3.1), et de considérer la préférence Nvu "reformatter la source HTML" comme "lancer le nettoyeur de balises [+Tidy] à chaque sauvegarde". La fenêtre du nettoyeur de balises servirait d'options avancées pour le reformattage.
Ca en reviendrait (quasiment) au même, et ça rendrait le truc plus compréhensible pour les néophytes. Peut-être pour la version 0.4.0...

installée
- Est ce normal de trouver

Code : Tout sélectionner

<?php // Generated by Nvu + HandCoder ?>

en première ligne de code avant le doctype? Simple question de débutant

- Plus de fenêtre intempestive

En toute rigueur, un fichier PHP devrait toujours commencer par <?php (avant le DOCTYPE donc), c'est ce qu'on appelle un prologue. Ca n'apparait pas dans la page qui est vue par le visiteur (comme toutes les pseudo-instructions PHP d'ailleurs), donc ce "marquage" n'est pas gênant.

Un des buts de HandCoder est de pouvoir ajouter un prologue PHP. Ca n'est réellement utile que pour des questions d'authentification d'utilisateur (cf. les pages HTML protégées), mais quitte à implémenter le support des prologues, c'était plus simple de faire en sorte que HandCoder ajoute un prologue "bidon" si le document initial n'en contient pas.

Accessoirement, pour le débug c'est très pratique (pour moi).

chinon37 a écrit :Plus de fenêtre intempestive

Le doctype html strict a l'air bon.

Un rikikibug : quand il y a le prologue handcoder dans un fichier alors on a deux LF apres la balise <head> au lieu de un LF. (une tentative de tri des balises ?

). Evidemment sans tidy !
Un coup de tidy et hop plus que un seul LF. Mais une modification dans nvu et les deux LF reviennent.

Questions subsidiaires :
Est-ce gênant si on a un fichier php (qui contient du php) ouvert dans nvu sans prologue ?
Est-ce gênant si on a un fichier html normal avec l'extension php ? (celui ne reçoit pas de prologue).
Apparemment le prologue s'ajoute uniquement lorsqu'il y a du php dans le fichier.

Do-IT a écrit :Le doctype html strict a l'air bon.

Je vais être le seul à garder mes pages en XHTML Strict...

Do-IT a écrit :une tentative de tri des balises ?

Non, même pas !
Réponse courte : ça devrait être corrigé pour la 0.3.4.

Réponse longue (et pense-bête perso) : à l'ouverture d'un fichier PHP, Nvu déplace le prologue juste après le <head>. HC déplace le prologue avant d'ouvrir le fichier PHP (ça évite certains désagréments) avec des transformations de texte, et le replace avant le doctype au moment de la sauvegarde (et dans l'affichage "Source") avec des méthodes DOM, qui ne connaissent pas les fins de ligne.

Cette méthode fonctionne assez bien, mais elle comporte deux défauts :

ça crée donc des fins de lignes "superfétatoires" (moi aussi je parle belge)
ça ne fonctionne pas quand le prologue est constitué de plusieurs noeuds DOM, comme dans l'exemple signalé par lerouxjul :
Code : Tout sélectionner
```
<?php echo <?xml version="1.0"?>"; ?>
<?php defined( '_VALID_MOS' ) or die( 'Direct Access to this location is not allowed.' ); ?>
```
car dans ce cas, le deuxième bloc PHP reste dans le <head>...

Pour couronner le tout, la ligne

Code : Tout sélectionner

<?php echo <?xml version="1.0"?>"; ?>

plante le parser de Nvu, à cause des deux ?>

Evidemment, c'est crétin de mettre deux blocs PHP en prologue, et le prologue XML lui-même est inutile (et même gênant). Mais ça a l'air d'être une pratique assez répandue, notamment pour les templates Joomla! ; donc il va falloir modifier cette méthode de support du prologue pour la version 0.3.4.

Do-IT a écrit :Est-ce gênant si on a un fichier php (qui contient du php) ouvert dans nvu sans prologue ?

Non, HC devrait juste ajouter un prologue bidon (Generated by Nvu + HandCoder).

Do-IT a écrit :Est-ce gênant si on a un fichier html normal avec l'extension php ? Apparemment le prologue s'ajoute uniquement lorsqu'il y a du php dans le fichier.

Ce n'est pas gênant, mais ce n'est pas très rigoureux non plus. Je n'ai pas pensé à ce cas-là.
Idéalement, un fichier *.php devrait toujours débuter par un prologue PHP.

Kaze a écrit :Ce n'est pas gênant, mais ce n'est pas très rigoureux non plus. Je n'ai pas pensé à ce cas-là.

J'en suis venu à ça en essayant de créer un fichier php juste avec nvu. C'est pas triste.

Nouveau document > Enregistrer > titre:test > Type:Tous les fichiers > Nom:test.php > Enregistrer.
Jusque là tout va bien, sauf si on laisse le choix par défaut pour le type:Fichiers HTML > Nom:test.php > dans ce cas le fichier sur le disque s'appelle testphp sans point.
J'ai donc mon test.php ouvert dans nvu, soit je le ferme et je l'ouvre plus tard (c'est le cas non prévu).
Soit j'intègre directement du php (Insertion > Code PHP). Dans ce cas je me retrouve avec un fichier php (avec du php), et sans prologue (vu que le prologue est ajouté à l'ouverture).
Mais si ça ne gêne pas le fonctionnement, alors tout va bien.

Kazé,
pendant que tu es sur Handcoder.... il y avait longtemps que je ne t'avais pas embêté avec ça, donc je reviens à la charge:
J'ai 6 sites de paramètrés en local (je publie tout par Filezilla) dont 3 en html et 3 en php (2 des 3 derniers à l'intérieur de Easyphp (dossier www)
Pour 2 de ces sites, 1 en php dans easyphp et 1 en php à la racine du DD, un clic droit sur les images fait apparaïtre la fenêtre suivante

au lieu de la fenêtre suivante:

Je précise que le paramétrage du gestionnaire de sites n'intervient pas: les 2 sites à l'intérieur de easyphp sont paramétrés de la même manière à la virgule près, (seule le nom du dossier change) et la réaction clic droit est différente.
Tiens, je constate que The gimp n'apparait plus?!?
Je constate que cette différence de réaction existe aussi pour les fichiers css:

au lieu de:

<je l'aurais, je l'aurais!>

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3

Si personne ne déniche de gros bug, je mettrai cette rc4 comme 0.3.3 finale ce week-end.

Do-IT a écrit :Jusque là tout va bien, sauf si on laisse le choix par défaut pour le type: Fichiers HTML

Effectivement.

Il faudrait que je bricole ça aussi. D'ailleurs, je ne vois pas bien l'intérêt de distinguer les fichier HTML de XHTML dans les filtres ; je préfèrerais avoir un type "Document HTML" au sens large et un type "Document Texte", conformes aux extensions de fichier spécifiées dans les options de HC.

Do-IT a écrit :Mais si ça ne gêne pas le fonctionnement, alors tout va bien.

Ca reste à améliorer pour les versions suivantes.

chinon37 a écrit :il y avait longtemps que je ne t'avais pas embêté avec ça, donc je reviens à la charge

Je me souviens que tu m'en avais parlé, mais je ne retrouve pas le message correspondant.
Peut-être celui-ci : http://geckozone.org/forum/viewtopic.ph ... 764#258764 ? (les copies d'écran ont disparu)

Ca m'a l'air d'être plutôt lié à NsmConText qu'à HandCoder, non ?
Quoiqu'il en soit, c'est un gros bug. Quelques questions en vrac :

y a-t'il quelque chose dans la console JS ? (corollaire : as-tu ton menu en JavaScript dans la page courante ?)
si tu ouvres le fichier pointé avec Firefox, est-ce que ça fonctionne ? (= ça ouvre bien le fichier pointé, et pas un autre)
quelle version de NsmConText utilises-tu ?
la désinstallation de HandCoder change-t'elle quelque chose ?

Evidemment, je n'ai pas pu reproduire ce bug.

Kaze a écrit :Si personne ne déniche de gros bug, je mettrai cette rc4 comme 0.3.3 finale ce week-end.

Fin du mois ce serait pas mieux ? Pour les autres OS et les autres utilisateurs.

Geckozone

HandCoder : extension Nvu pour Tidy et PHP