KompoZer 0.8 alpha3

[Do-IT]

Dans un texte sans structure, j'impose un <p> par la liste déroulante des structures. Positionné au dernier caractère, je frappe Enter. Résultat:

D'après mes essais, le paragraphe se créé une fois sur deux. Au 1er Enter => <br>, au 2eme Enter => paragraphe, au 3eme => <br>, etc.... A condition de faire le Enter dans un paragraphe.
Ceci quelle que soit la valeur du menu > Outils > Préférences > Avancées > Comportement de la touche entrée.

ps: La fenêtre Préférences s'appelle Options. (pb traduction ?)

[Do-IT]

Sous Jaunty, j'ai Firefox et Opera. Avec la commande

Code : Tout sélectionner

sudo update-alternatives –config x-www-browser

je choisis le navigateur par défaut.

Opera par défaut :
- Dans un terminal, x-www-browser ouvre Opera,
- Dans Thunderbird, un clic sur un lien ouvre Firefox,
- Sur le bureau, un clic sur un raccourci URL ouvre Firefox,
- Kompozer ouvre Opera + message

Code : Tout sélectionner

FileIO: opened file 'http://kompozer.sourceforge.net/'

Firefox par defaut :
- Dans un terminal, x-www-browser ouvre Firefox,
- Dans Thunderbird, un clic sur un lien ouvre Firefox,
- Sur le bureau, un clic sur un raccourci URL ouvre Firefox,
- Kompozer n'ouvre rien + message

Code : Tout sélectionner

FileIO: opened file 'http://kompozer.sourceforge.net/'

[Do-IT]

Personnalisation des barres d'outils > Montrer : Texte > Petites icônes : cochée > Terminer
Personnalisation des barres d'outils > Montrer : Texte et icônes (ou Icônes) > La case petites icônes devrait être coché puisque les icônes affichées sont petites.

D'ailleurs en mode > Montrer : Texte > La taille du texte n'est pas la même si la case Petites icônes était cochée préalablement ou pas.

Déjà connu : Personnalisation des barres d'outils > Configuration par défaut > Grandes icônes sans texte (normal ?) > Terminer > impossible de retourner dans Personnalisation +

Code : Tout sélectionner

Erreur : gToolbox.toolbarset has no properties
Fichier source : chrome://global/content/customizeToolbar.js
Ligne : 150

[Kazé]

Ah, j’ai de quoi m’occuper pour un moment là.
Je prends bonne note de tous les bugs, il y a de très bonnes suggestions, mais dans l’immédiat je vais me focaliser sur la correction des régressions sur l’alpha4, histoire de publier aussi vite que possible. Je ne voudrais pas qu’Ubuntu utilise l’alpha3 dans Karmic Koala.

Je commence par dépiler les suggestions :

A l'ouverture d'un nouvel onglet, il y a basculement forcer en mode conception.
Suggestions :
- garder le mode du dernier onglet,
- forcer l'ouverture dans le mode de son choix (mixte),
- mémoriser le mode pour chaque onglet,

Oui, effectivement.
J’avais choisi le mode Conception par défaut parce que c’est le plus économe en ressources, mais il faudrait laisser l’utilisateur en décider.
Pour l’instant j’ai contourné le problème en utilisant le raccourci Alt+Enter pour forcer le passage en mode Mixte.

- garder les onglets du haut en mode source.

Pas simple. Mieux vaut utiliser Geany ou BlueFish pour ça.

Le fonctionnement de la poignée du mode mixte me plait pas. Lorsqu'on descend la poignée au max vers le bas on se retrouve quasiment en mode conception.

La poignée du mode Mixte était bien adaptée à l’alpha2, mais elle ne l’est plus du tout à l’alpha3. Ça ne me convient pas non plus.

Suggestions :
- Ajouté cette poignée au mode conception pour pouvoir basculer en mode mixte avec un gain de un clic. (car après il faut régler la taille du dock)

On a déjà plus ou moins ça dans la mesure où on peut minimiser le dock source en mode Mixte. Pour l’instant ça ne sert pas à grand-chose puisque KompoZer 0.8a3 ne mémorise pas le mode d’édition d’un onglet à l’autre.

- Lorsque la poignée est au max vers le haut basculer vers le mode source ? (c'est chaud mais faudrait expérimenter)
- Garder la poignée (en haut) en mode source et basculer vers le mode mixte si on baisse la poignée.

La poignée du mode Mixte était bien adaptée à l’alpha2, mais elle ne l’est plus du tout à l’alpha3. Ça ne me convient pas non plus. [/quote] Intéressant !
On pourrait utiliser la poignée pour tout, et KompoZer passerait d’un mode à l’autre (Conception / Mixte / Source) en fonction de la taille laissée à chaque zone. À essayer !

Barre d'état > À quoi sert <html> ?

Avec le mode Source, il est effectivement moins utile qu’avant.
Néanmoins, il reste pratique pour visualiser le code source et surtout pour éditer le nœud <head>. Et je compte bien proposer à terme une préférence pour ne pas avoir de mode source du tout, par exemple :
Mode Source:

• avec coloration syntaxique
• sans coloration syntaxique (plus rapide) <-- par défaut ?
• aucun (utiliser un éditeur externe)

Puisque je cherche à garder un logiciel qui soit utilisable sans ce mode Source, il faut que le dock remplisse les besoins du mode Source.

[Do-IT]

Ma dernière tentative pour retarder l'alpha 4.

Outils > Préférences > Gestionnaire de site > Décocher : Toujours ouvrir...
Ouvrir kz > Ouvrir une page > S'affiche dans le 1er onglet > Ouvrir 2eme page > Ouvre un 2eme kompozer vide.

Pour moi décocher 'Toujours ouvrir un document dans un nouvel onglet' ça pourrait vouloir dire que le le 2eme fichier remplace le 1er dans le 1er onglet ?
Peut-être d'une liste déroulante ou des bouton radio avec comme 2eme texte : Toujours ouvrir un 2eme document dans une nouvelle fenêtre kompozer.

Si c'est bien ça le fonctionnement souhaité.

[Kazé]

On passe aux bugs :

Édition dans le dock source (sans valider) > Changer d'onglet > Modifications perdues.

Effectivement. Je ne sais plus si je l’ai fait exprès ou pas.

Ouvrir kz > Ouvrir une page > Ouvrir une 2eme page (ou un nouvel onglet) > Clic 1er onglet (pour retourner sur le 1er onglet) > Ctrl-R (long, 2 sec) > Alertes et Erreurs variables en fonction de la page ouverte (Fenêtre d'alerte : Cette page n'a pas pu être éditer pour une raison inconnue)

Rhaaa, le bon vieux filon de bugs sur deux onglets.
Un onglet ça va, trois onglets ou plus aussi, mais sur deux onglets on a tout un tas de comportements bizarres. Il faut que je me penche plus sérieusement sur le binding "tabeditor.xml".

Ouvrir kz >Ctrl-n > Erreur

Joli. Avec le bouton ou les menus, ça ne se produit pas. Voilà peut-être une piste pour savoir pourquoi
l’ouverture d’une page dans une nouvelle fenêtre ne fonctionne pas, comme tu l’as signalé plus loin :

Outils > Préférences > Gestionnaire de site > Décocher : Toujours ouvrir...
Ouvrir kz > Ouvrir une page > S'affiche dans le 1er onglet > Ouvrir 2eme page > Ouvre un 2eme kompozer vide.

Je n’avais pas trouvé de piste pour l’instant. Peut-être que le coup du Ctrl+N va me guider ; dans le cas contraire, je contournerai la difficulté en faisant en sorte que Ctrl+N ouvre une nouvelle fenêtre vide, et je supprimerai les options qui permettent d’ouvrir un document dans une nouvelle fenêtre : les documents seraient alors systématiquement ouverts dans un nouvel onglet de la fenêtre courante, si on veut une nouvelle fenêtre il faudra la demander explicitement avec Ctrl+N ou Fichier > Nouvelle fenêtre.

Dans un texte sans structure, j'impose un <p> par la liste déroulante des structures. Positionné au dernier caractère, je frappe Enter. Résultat:

D'après mes essais, le paragraphe se créé une fois sur deux. Au 1er Enter => <br>, au 2eme Enter => paragraphe, au 3eme => <br>, etc.... A condition de faire le Enter dans un paragraphe.
Ceci quelle que soit la valeur du menu > Outils > Préférences > Avancées > Comportement de la touche entrée.

C’est ça. Le comportement de [Enter] ne me gêne pas (c’est celui de Thunderbird), mais le fait qu’il ne corresponde pas aux options est un bug.
Pour être précis, c’est tout simplement un point que je n’ai pas encore implémenté. Ça fait partie du patch que je dois adapter de Nvu à KompoZer 0.8 sur le sérialiseur html/xhtml, qui permet (entre autres) la pseudo-colorisation syntaxique, le contrôle de l’encodage des attributs pour le PHP et la réduction du nombre de <br> dans le code HTML.
Je m’y collerai pendant la phase bêta.

[Kazé]

Pour finir, les détails d’interface qui attendront la phase bêta :

ps: La fenêtre Préférences s'appelle Options. (pb traduction ?)

Contrairement aux apparences, c’est un problème de code (et non de traduction), qui est hérité de Nvu.
En toute rigueur, la fenêtre de préférences devrait être dans Outils > Options sous Windows, Édition > Préférences sous Linux, et dans le menu « pomme » sous Mac. Là c’est un peu n’importe quoi, il faudra que je m’y colle.

Personnalisation des barres d'outils

Oui, c’est farci de bugs. Merci pour la liste, il y en a que je n’avais pas vus.

Sous Jaunty, j'ai Firefox et Opera. Avec la commande

Code : Tout sélectionner

sudo update-alternatives –config x-www-browser

je choisis le navigateur par défaut.

Oui, je m’attends à pas mal de cas tordus pour ça. Le support des applications externes n’est pas immédiat dans les technologies Mozilla, il faudrait que je me fende d’un article sur la question un jour. Pour ne rien arranger, il y a plusieurs façons de spécifier des applications par défaut sous Linux, qui dépendent à la fois de la distribution (DEB / RPM) et du bureau (KDE / Gnome).

Quoiqu’il en soit, c’est la raison pour laquelle le code qui servait à lancer des applications externes dans NsmConText et HandCoder a été intégré dans KompoZer : ça facilitera le débug, ça évitera les conflits entre extensions, et dans l’immédiat ça permet déjà de forcer l’utilisation d’un navigateur bien défini.
Par contre, c’est vrai que ça nécessite encore un peu de peaufinage :

• dans la fenêtre de préférences > Applications externes, le bouton « Parcourir… » devrait proposer un répertoire pertinent selon la plate-forme hôte (/Applications sous Mac, /usr/bin sous Linux)
• quand on demande une application qui n’est pas (ou mal) spécifiée, comme par exemple l’ouverture de la page courante dans un navigateur ou un éditeur texte, il faudrait une boite de dialogue pour proposer de choisir un navigateur / éditeur par défaut
• maintenant que NsmConText ne sert plus à rien, il faudrait que je bosse avec Henrik Gemal sur Launchy pour qu’il s’intègre mieux à KompoZer 0.8

Dans les détails à prévoir pour la suite, il y a aussi le fait qu’il faudrait avoir un moyen de spécifier l’emplacement des applications externes en relatif par rapport à l’exécutable KompoZer, pour faciliter l’utilisation depuis une clé USB.

[Manusnake]

Histoire de te compliquer la tâche.
J'ai créé cette page : http://secondeguerre.net/k8043.html qui est simplement celle-ci : http://www.secondeguerre.net/articles/e ... rance.html

Tout ce que j'ai fais, c'est l'ouvrir dans Kompozer, l'enregistrer de nouveau sous un autre nom et l'envoyer sur le site.

Sous Safari et Opera, pas de soucis, mais sous Firefox... Il n'y a que le début de la page qui apparaisse, alors que le Validator du W3C dit que tout est propre.

De plus le code, bien qu'un peu changé, semble bon. Si ce n'est un détail, la coloration syntaxique du code dans Firefox s'arrête au même niveau que le rendu de la page dans le navigateur.

Dans Kompozer, toute la page apparaît sans soucis...

J'ai cependant trouvé le soucis, à cette ligne de code :

Code : Tout sélectionner

<td><script type="text/javascript" src="http://affileo.net/pass/js.php?c=CgAAALkFAABfAQAA&s=p&width=196" /></script>

Kompozer la remplace par ça :

Code : Tout sélectionner

<td><script type="text/javascript" src="http://affileo.net/pass/js.php?c=CgAAALkFAABfAQAA&s=p&width=196" />

Il vire donc la balise de fermeture du script, le vilain... Une idée ?

Message envoyé avec : Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4

[Kazé]

Mmhhh, ça s’arrête à la ligne

Code : Tout sélectionner

<script type="text/javascript"
 src="http://affileo.net/pass/js.php?c=CgAAALkFAABfAQAA&s=p&width=196" />

As-tu essayé de fermer explicitement la balise <script> ?

Code : Tout sélectionner

<script type="text/javascript"
 src="http://affileo.net/pass/js.php?c=CgAAALkFAABfAQAA&s=p&width=196"></script>

Il te faudra passer par un éditeur externe pour ça. Si ça résoud le problème, je peux corriger ça coté KompoZer, mais ça sera pour l’alpha5.

[Edit] Grillé. Bah ça sera au menu de l’alpha5.
Ça fait partie de ce que je dois implémenter dans le sérialiseur html/xhtml. [/Edit]

[Manusnake]

Ouaip, je me suis rendu compte du problème juste après avoir posté.

J'espère que ce ne sera pas trop compliqué à mettre dans l'alpha5.

Sinon le reste du code semble aller. Je te signalerai les autres soucis si j'en vois.

Ce que je m'explique mal, c'est que ça valide, que Safari et Opera rendent la page, mais que FF ne le fait pas. Il est plus catholique que le pape ? Toujours est-il que, pour moi, ne pas fermer une balise en XHTML est une faute, d'où mon incompréhension de la validation (peut-être parce que c'est du transitionnal remarque).

Message envoyé avec : Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4

[Do-IT]

Pourquoi cette balise </script> est elle bouffée alors que les autres au-dessus ne le sont pas ? A cause du contenu spécifique ? js.php?c=CgAAALkFAABfAQAA&s=p&width=196"

Puis il y a aussi une différence au-dessus du doctype. <?xml version="1.0" encoding="UTF-8"?>

En tout cas moi ce que j'en pense du xhtml !!!

[Edit] Testé avec une page xhtml créé par kz, idem il n'aime pas le contenu du lien de ce script.
Quant au contenu du dock source y'a du _moz à toutes les sauces[/edit]

[Manusnake]

Pourquoi cette balise </script> est elle bouffée alors que les autres au-dessus ne le sont pas ? A cause du contenu spécifique ? js.php?c=CgAAALkFAABfAQAA&s=p&width=196"

Puis il y a aussi une différence au-dessus du doctype. <?xml version="1.0" encoding="UTF-8"?>

En tout cas moi ce que j'en pense du xhtml !!!

Bonne question... Pourquoi elle et pas les autres ? Mais bon, Kazé semble savoir par quel bout prendre le problème.

Pour cette ligne : <?xml version="1.0" encoding="UTF-8"?>, Kompozer l'a toujours virée, et certains sites fiables écrits en XHTML (genre http://www.webstandards.org/) ne l'ont pas non plus.

Par contre http://www.w3.org/ l'a, alors je ne sais trop quoi penser... Pourrait-on ajouter une option pour qu'elle reste ? Elle sert bien a déterminer le type de document XML non ? J'admets que sur internet, c'est moyennement utile (vu que ça va rendre en HTML), mais quand même.

Message envoyé avec : Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4

[/jmj]

Salut,

J'ouvre une page avec une feuille de style. Je lance l'éditeur css. Je modifie un truc. Je le ferme. Je le relance, j'ai *|#mondiv à la place de#mondiv. Je ferme la page. Je relance la page avec le gestionnaire. Je relance l'éditeur css. ok, tout va bien. Je le ferme, le relance. Parfois normal, parfois *|#mondiv.

C'est plus ou moins aléatoire et parfois, si j'ajoute une autre feuille de style ; la précédente est enregistrée avec *|#mondiv mais pas tout le temps alors que la nouvelle est enregistrée correctement.

Les modifications dans l'éditeur css sont enregistrées automatiquement, parfois pas du tout.

Et le bug des bordures à la première manip est toujours là.





Message envoyé avec : Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.8) Gecko/2009033116 Mandriva/1.9.0.8-0.1mdv2009.0 (2009.0) Firefox/3.0.8

[Kazé]

Pourquoi cette balise </script> est elle bouffée alors que les autres au-dessus ne le sont pas ?

Je ne sais pas, mais c’était un bug connu d’IE6. Je suis un peu surpris de le voir dans Firefox 3 !
Quoiqu’il en soit, dans le sérialiseur xhtml on peut donner une liste d’éléments qui ne sont pas « compactables », i.e. qu’on ne peut pas mettre sous la forme :

Code : Tout sélectionner

<element />

au lieu de

Code : Tout sélectionner

<element></element>

lorsque <element> est vide. Il suffira que j’ajoute <script> à la liste, comme c’était le cas avec KompoZer 0.7.

[Edit] Testé avec une page xhtml créé par kz, idem il n'aime pas le contenu du lien de ce script.
Quant au contenu du dock source y'a du _moz à toutes les sauces[/edit]

Oui, il y a du boulot coté xhtml, mais ce n’est pas prioritaire en phase alpha.

Pour cette ligne : <?xml version="1.0" encoding="UTF-8"?>, Kompozer l'a toujours virée, et certains sites fiables écrits en XHTML (genre http://www.webstandards.org/) ne l'ont pas non plus.

De mémoire, cette ligne est à éviter car elle fait passer IE en mode de rendu "quirks", i.e. non standard. De mémoire toujours, cette ligne n’a d’intérêt que si on encode une page xhtml avec autre chose que de l’utf-8.
À l’époque de KompoZer 0.7, j’en avais déduit qu’on ne pouvait faire du xhtml propre qu’en utf-8 (ce qui n’est pas sans conséquence coté KompoZer, surtout vu ce que Tidy fait des espaces insécables en utf-8), mais il faudra que je regarde ça plus précisément. J’avais résolu le problème en passant mes sites en HTML 4.01, Calimo nous ayant expliqué en quoi le XHTML est inutile voire néfaste sur le web. Depuis, je n’utilise le XHTML que pour mes besoins de documentation, car ça permet de faire des transformations XSL et d’inclure des éléments type MathML ou SVG proprement.

En tout cas moi ce que j'en pense du xhtml !!!

Pour du site ouèbe, le seul intérêt que je voie au xhtml c’est le support SVG sans passer par <object> ; mais :

• vu que IE ne supporte toujours pas le "vrai" XHTML (i.e. envoyé en application/xhtml+xml)
• vu que IE ne supporte pas le SVG nativement
• vu que les navigateurs modernes vont supporter le SVG dans les images (genre : <img src="logo.svg">)
• et vu les spécifications HTML 5 qui sont vraiment super bien fichues pour le ouèbe (multimédia, navigation, syntaxe simple)

je parierais que le XHTML va passer de mode sur la toile, et qu’il redeviendra un (excellent) format de documentation. Dans les rapports de bugs et requêtes d’améliorations que je reçois, j’ai déjà plus de demandes pour du HTML5 que pour du XHTML.

[Kazé]

Salut JMJ,

J'ouvre une page avec une feuille de style. Je lance l'éditeur css. Je modifie un truc. Je le ferme. Je le relance, j'ai *|#mondiv à la place de#mondiv. Je ferme la page. Je relance la page avec le gestionnaire. Je relance l'éditeur css. ok, tout va bien. Je le ferme, le relance. Parfois normal, parfois *|#mondiv.

Oui, déjà signalé dans le sujet spécifique à l’éditeur CSS : http://www.geckozone.org/forum/viewtopic.php?t=73299
Note que la notation *| reste parfaitement valide.
Je vais voir si je peux filtrer ça. Ce n’est pas prioritaire pour l’instant, mais ça sera corrigé pendant la phase bêta au plus tard.

Les modifications dans l'éditeur css sont enregistrées automatiquement, parfois pas du tout.

Sans une procédure pour reproduire le bug, je vais avoir du mal à le corriger celui-là…
Y a-t’il une erreur dans la console JavaScript quand ça se produit ? Pourrais-tu poster une procédure pas-à-pas (avec une page HTML si besoin est) STP ?

Et le bug des bordures à la première manip est toujours là.

Vu qu’il a été signalé dans ce sujet sur l’alpha3 et que l’alpha4 n’est toujours pas sortie, je suis tenté de trouver ça rassurant.
D’ici là, il faudra cliquer deux fois sur la case « même style pour les quatre cotés ».