KompoZer 0.8 alpha4

Invité · Message par **Invité** » 12 août 2009, 22:01

Chez moi, ce fichier s’ouvre directement dans KompoZer 0.8a5-pre :

<?php // generated by KompoZer ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="content-type">
    <title>KompoZer - Easy web authoring</title>
    <link rel="shortcut icon" type="image/x-icon" href="/favicon.ico">
    <link rel="stylesheet" href="/style.css" type="text/css">
  </head>
  …

Ymai : as-tu bien désactivé HandCoder pour faire ce test ? Ou mieux, créé un nouveau profil ?

Message envoyé avec : Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.0.13) Gecko/2009080316 Ubuntu/8.04 (hardy) Firefox/3.0.13

Kazé · Message par **Kazé** » 12 août 2009, 22:07

J’avions oublié de me logger…

Message par **Ymai** » 12 août 2009, 22:45

Une précision nécessaire: je tente d'ouvrir ces fichiers .php depuis le gestionnaire de sites.
Après désinstallation de Handcoder: pas mieux
Suppression du profil et redéfinition du site: pas mieux.

Mais > File > Open File > bidule.php => le fichier s'ouvre dans KpZ

Message envoyé avec : Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

Kazé · Message par **Kazé** » 12 août 2009, 23:15

Ah, la précision était effectivement nécessaire.

Dans les préférences de KompoZer (section « Helper Applications »), il faudrait faire passer *.php de la section « text files » vers la section « html documents »… avec les risques que ça implique pour l’utilisateur.
Une fois cette préférence redéfinie, et le gestionnaire de sites redémarré, on peut ouvrir un fichier *.php depuis le gestionnaire de sites.

Plus généralement : il faudrait que les boites de dialogues proposent les mêmes filtres que ceux définis pour le gestionnaires de sites dans la section « Helper Applications » des préférences. Ça m’éviterait de me demander systématiquement où sont les fichiers *.php quand je fais un File > Open…

Message par **Ymai** » 13 août 2009, 23:57

OK, mais KpZ ouvre alors *tous* les fichiers .php, y compris ceux qui ne devraient être ouverts que par un éditeur externe. Et il rajoute même un Doctype et divers bouts de HTML (<head><body>...) qui n'ont rien à faire là

.
L'intelligence de KpZ 0.7.10 -qui fait bien la distinction- ne peut pas être perfusée à KpZ 0.8 ?

Message envoyé avec : Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

Kazé · Message par **Kazé** » 14 août 2009, 02:06

Ymai a écrit :L'intelligence de KpZ 0.7.10 -qui fait bien la distinction- ne peut pas être perfusée à KpZ 0.8 ?

Sauf erreur, « l’intelligence » n’est pas du fait de KompoZer 0.7.10 mais de HandCoder 0.3.

L’idée générale est d’avoir le même comportement entre Windows et Linux, i.e. d’ouvrir un document *.php dans KompoZer par défaut. Après tout, si on enregistre un fragment HTML et qu’on l’ouvre avec KompoZer, il va rajouter aussi des nœuds <html>, <head>, <body> et un Doctype…

Ceci dit, je peux essayer de faire en sorte que KompoZer refuse d’ouvrir un document *.php s’il ne contient pas les nœuds <html>, <head>, <body> — du moins, quand HandCoder n’est pas installé.

Message envoyé avec : Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

Zefling · Message par **Zefling** » 14 août 2009, 10:17

Je suis de retour de petits tests.

Bon, je remarque les images ne sont plus des éléments bloquant lorsque l'on se déplace au clavier. C'est pas mal ça. Par contre, ce qu'il serait bien c'est que lors qu'on a sélectionné une image que l'on fait ← ou → le curseur se place à côté de l'image, car si l'image se trouve en début de bloc ou de ligne, il est impossible de se placer à côté de l'image pour ajouter quelque chose. Quand on se déplace avec les flèches, les images sont ignorées et dans l'autre sens je me retrouve directement après ou avant l'image.

J'aurais une autre suggestion du même genre. Pour la sélection des éléments dans la barre du bas ( html > body > div > span). Quand je sélectionne l'élément span que je fais fait ←, il ne se place pas avant le span, mais recule d'un à partir du début du span. En fait, j'aimerais qu'il soit plus facile de place à l'extérieur ou l'intérieur proche d'un nœud de façon simple, ce qui n'est pas du tout le cas pour l'instant.

Personnellement, ça ne me dérangerait pas qu'il y ait un mode qui fasse que de passer dans un nœud demande à faire plus de déplacement avec les flèches, un peu comme ceci (et qu'il n'ignore pas les images) :

Code : Tout sélectionner

[→]    t|e<span>st</span>.
[→]    te|<span>st</span>.
[→]    te<span>|st</span>.
[→]    te<span>s|t</span>.
[→]    te<span>st|</span>.
[→]    te<span>st</span>|.

Par contre, quand j'ai édité une image que j'ai copier/coller avec une bordure, celle-ci à disparue.
Quand je fais « alignement à gauche » j'ai toujours align="right", peut-être une erreur dans le pack français. Quand je demande à avoir une bordure de 2 il ne fait rien si je ne coche pas encadrer les images avec un lien s’il y a effectivement un lien. Mais franchement je n’arrive pas à voir la différence. Au final, c'est le même code qui est ajouté : border: 2px solid ;

(Je note tout de même que la vu source est totalement sans intérêt sans coloration sur un document important, j'ai trop de mal à trouver ce que je cherche)

Dans la vue split, il y a bien la coloration, mais sans retour à la ligne sur une balise, j'ai certains éléments qui sont d'une longueur qui ne permet pas une bonne lisibilité (une image avec une alt assez long, un title assez long, une url assez longue et un style, ça fait 4 écrans de larges)

Serait-il possible d'ajouter l'alignement vertical pour l'édition des images. Genre parfois, pour certaines images placée dans le texte, j'aime les passer en vertical-align:middle, par défaut c'est en baseline.

Voilà. J'espère que je suis compréhensible.

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

Kazé · Message par **Kazé** » 14 août 2009, 19:01

Pour tout ce qui concerne le placement du curseur, je corrigerai ce que je pourrai durant la phase bêta.
Je suis assez d’accord avec tes remarques sur ce point précis, mais malheureusement ce n’est pas si simple à implémenter. C’est un problème récurrent, qu’on retrouve aussi dans Thunderbird…

Zefling a écrit :Par contre, quand j'ai édité une image que j'ai copier/coller avec une bordure, celle-ci à disparue. […]
Quand je demande à avoir une bordure de 2 il ne fait rien si je ne coche pas encadrer les images avec un lien s’il y a effectivement un lien. Mais franchement je n’arrive pas à voir la différence. Au final, c'est le même code qui est ajouté : border: 2px solid ;

Pour ce qui concerne les bordures des images, voir le message de /jmj fin juillet.
La façon dont sont appliquées les bordures sur les liens image n’est pas satisfaisante, il faudrait améliorer ça — j’ai fait des propositions en ce sens plus haut.

Zefling a écrit :Quand je fais « alignement à gauche » j'ai toujours align="right", peut-être une erreur dans le pack français.

Ce n’est pas une erreur de traduction : c’est le texte qui est aligné à gauche, et non l’image. Je sais, c’est tordu.
Le vrai bug, c’est que l’image qui est censée illustrer la position de l’image est manquante dans KompoZer 0.8. À corriger.

Zefling a écrit :Serait-il possible d'ajouter l'alignement vertical pour l'édition des images. Genre parfois, pour certaines images placée dans le texte, j'aime les passer en vertical-align:middle, par défaut c'est en baseline.

Si on me propose une maquette pour l’interface de la boite de propriétés, pas de problème.
Par contre, je ne suis pas certain que tous les navigateurs comprennent bien le "vertical-align"… Quelqu’un pourrait-il me rencarder sur le sujet ?

Zefling a écrit :(Je note tout de même que la vu source est totalement sans intérêt sans coloration sur un document important, j'ai trop de mal à trouver ce que je cherche)

L’onglet source est une ignoble verrue, et l’ajout de la coloration syntaxique le rendra encore pire.
Il y a un bouton « Éditeur » pour ouvrir le document courant dans un vrai éditeur texte, je ne saurais trop en recommander l’utilisation.

Ceci dit, et comme je l’ai signalé plus haut : je suis en train de repenser cet onglet « Source », et le nouveau dock source qui est proposé dans le snapshot alpha5-pre (pour GNU/Linux) devrait préfigurer du futur onglet « Source ». J’attends d’avoir plus de retour sur ce nouveau dock source avant de refaire l’onglet « Source » sur la même base… et ça n’aura lieu que pendant la phase bêta, de toute façon.

Zefling a écrit :Dans la vue split, il y a bien la coloration, mais sans retour à la ligne sur une balise, j'ai certains éléments qui sont d'une longueur qui ne permet pas une bonne lisibilité (une image avec une alt assez long, un title assez long, une url assez longue et un style, ça fait 4 écrans de larges)

Si tu as l’alpha4 ou une version antérieure : clic droit > "wrap long lines"
Pour l’alpha5 je vais simplifier au maximum ce dock source, et les lignes seront toujours « wrappées ».

Message envoyé avec : Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

Message par **Ymai** » 14 août 2009, 20:03

Kazé a écrit :L’onglet source est une ignoble verrue, et l’ajout de la coloration syntaxique le rendra encore pire.

A ce sujet, est-il possible de vérifier que l'onglet source a le même comportement que chez moi?
Pour le code suivant en HTML strict ou transitionnel, entré dans l'onglet source, dans un fichier tout neuf:

Code : Tout sélectionner

<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
<title></title>
</head>
<body>
<?php
$MonMail = "toto@mail.com";
$sujet = "Mon sujet";
$envoi = "Le texte du mail";
$zorglub = "zorglub@mail.com
mail ($MonMail, $sujet, $envoi, "From: $nom <$zorglub>");
?>
</body>
</html>

je quitte le Source => des choses anormales apparaissent derrière la balise [php].
Je retourne dans l'onglet Source et je trouve

Code : Tout sélectionner

<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
<title></title>
</head>
<body>
<?php $MonMail = "toto@mail.com";
$sujet = "Mon sujet";
$envoi = "Le texte du mail";
$zorglub = "zorglub@mail.com
mail ($MonMail, $sujet, $envoi, "From: $nom <$zorglu?>");
?>
</body>
</html>

Encore plus fort, en XHTML strict ou transitionnel, c'est tout le code PHP qui disparaît.

eviv bulgroz (remarque pour les plus fins lettrés de ce forum

)

Message envoyé avec : Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

Zefling · Message par **Zefling** » 14 août 2009, 20:42

Kazé a écrit :Pour tout ce qui concerne le placement du curseur, je corrigerai ce que je pourrai durant la phase bêta.
Je suis assez d’accord avec tes remarques sur ce point précis, mais malheureusement ce n’est pas si simple à implémenter. C’est un problème récurrent, qu’on retrouve aussi dans Thunderbird…

J'espère que tu trouveras comment faire. Parce celle oblige à passer par la source (que tu aimes tant) pour ajouter du texte, ce qui n'est pas très logique.

Kazé a écrit : Pour ce qui concerne les bordures des images, voir le message de /jmj fin juillet.
La façon dont sont appliquées les bordures sur les liens image n’est pas satisfaisante, il faudrait améliorer ça — j’ai fait des propositions en ce sens plus haut.

Okay.

Bon je vais en ajouter une couche les espacements :
En XHTML hspace="2" vspace="2" en strict, c'est interdit.
Il faudrait le remplacer par du : padding: 2px 2px; pour faire plus propre.

Kazé a écrit :Ce n’est pas une erreur de traduction : c’est le texte qui est aligné à gauche, et non l’image. Je sais, c’est tordu.
Le vrai bug, c’est que l’image qui est censée illustrer la position de l’image est manquante dans KompoZer 0.8. À corriger.

En effet, j'avais même pas fait gaffe, mais pas logique

Kazé a écrit :
Zefling a écrit :Serait-il possible d'ajouter l'alignement vertical pour l'édition des images. Genre parfois, pour certaines images placée dans le texte, j'aime les passer en vertical-align:middle, par défaut c'est en baseline.
Si on me propose une maquette pour l’interface de la boite de propriétés, pas de problème.
Par contre, je ne suis pas certain que tous les navigateurs comprennent bien le "vertical-align"… Quelqu’un pourrait-il me rencarder sur le sujet ?

En fait, vertical-align et float sont en HTML « ALIGN » qui rassemble les deux.
http://www.htmlcodetutorial.com/images/_IMG_ALIGN.html

Bien sûr pour faire chier, ALIGN n'est pas valide XHTML.

En fait, il faudrait juste ajouter à « position de l'image » (et pas du texte

)

Kazé a écrit :L’onglet source est une ignoble verrue, et l’ajout de la coloration syntaxique le rendra encore pire.
Il y a un bouton « Éditeur » pour ouvrir le document courant dans un vrai éditeur texte, je ne saurais trop en recommander l’utilisation.

Ceci dit, et comme je l’ai signalé plus haut : je suis en train de repenser cet onglet « Source », et le nouveau dock source qui est proposé dans le snapshot alpha5-pre (pour GNU/Linux) devrait préfigurer du futur onglet « Source ». J’attends d’avoir plus de retour sur ce nouveau dock source avant de refaire l’onglet « Source » sur la même base… et ça n’aura lieu que pendant la phase bêta, de toute façon.

Indenté avec la coloration, ça va.
En bordel sans coloration,... heu...

Kazé a écrit :Si tu as l’alpha4 ou une version antérieure : clic droit > "wrap long lines"
Pour l’alpha5 je vais simplifier au maximum ce dock source, et les lignes seront toujours « wrappées ».

Merci pour l'astuce.

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

Kazé · Message par **Kazé** » 15 août 2009, 04:26

Je crois que je viens d’exterminer les avertissements du genre :

Code : Tout sélectionner

Warning: Expected color but found 'mixed'.  Error in parsing value for property 'background-color'.  Declaration dropped.
Source File: chrome://editor/content/editor.xul

Rien de révolutionnaire pour Mme Michu, mais ça va sérieusement alléger le contenu de la console JavaScript.

Ymai a écrit :
Kazé a écrit :L’onglet source est une ignoble verrue, et l’ajout de la coloration syntaxique le rendra encore pire.
A ce sujet, est-il possible de vérifier que l'onglet source a le même comportement que chez moi?

C’est possible, en effet.

Même comportement avec le dock source et l’onglet source.

C’est la ligne :

Code : Tout sélectionner

mail ($MonMail, $sujet, $envoi, "From: $nom <$zorglub>");

qui met le bazar. Avec

Code : Tout sélectionner

mail ($MonMail, $sujet, $envoi, "From: $nom $zorglub");

le problème disparaît, ce qui montre que la reconnaissance de la fin du bloc PHP (?>) est mal implémentée.
À corriger, au plus tard pendant la phase bêta.

Zefling a écrit :En XHTML hspace="2" vspace="2" en strict, c'est interdit.
Il faudrait le remplacer par du : padding: 2px 2px; pour faire plus propre.
[…]
Bien sûr pour faire chier, ALIGN n'est pas valide XHTML.

Même si c’est valide en HTML transitionnel, ça n’est pas une raison pour que KompoZer fasse ce genre de choses : on devrait toujours privilégier l’utilisation du CSS plutôt que de recourir à des attributs HTML.
C’est un gros boulot à prévoir, tant au niveau du code que pour l’interface utilisateur. Vu le planning, et vu que c’est déjà le cas avec KompoZer 0.7 (sauf erreur, la flemme de vérifier), je risque de reporter ça à après la sortie de la version 0.8.

Zefling a écrit :Indenté avec la coloration, ça va.
En bordel sans coloration,... heu...

L’onglet « Source » est le cadet de mes soucis à l’heure actuelle. Je bosserai dessus quand la vue splittée sera au point, pas avant.

Message envoyé avec : Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

pascalmac78 · Message par **pascalmac78** » 15 août 2009, 10:52

Bonjour et tout mon soutien pour le développement de Komposer.
J'en ai été un utilisateur plutôt assidu ces dernières années, mais je l'utilise maintenant de moins en moins depuis que je travaille sous XHTML. J'ai pu remarquer que l'utilisation de Komposer rendait les pages non valides W3C (erreurs de syntaxe principalement (<br>, ...).
C'est un grand regret, et je suis attentif à toute évolution permettant de nouveau de retravailler avec Komposer, sous XHTML ou les standards à venir.
Mon recours est maintenant un éditeur avec lequel j'écris "à la main" (Coda).

Tout mon soutien encore pour ce travail avec Komposer.

Bien cordialement,
Pascal

Message envoyé avec : Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_4_11; fr) AppleWebKit/531.9 (KHTML, like Gecko) Version/4.0.3 Safari/531.9

Message par **Ymai** » 15 août 2009, 11:35

Kazé a écrit :L’onglet « Source » est le cadet de mes soucis à l’heure actuelle. Je bosserai dessus quand la vue splittée sera au point, pas avant.

On vote où pour que cet onglet re-disparaisse? Au moins momentanément.
Pas la peine de se mettre la pression là-dessus alors que la vue "split" me paraît largement suffisante, voire bien supérieure.

Message envoyé avec : Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

Zefling · Message par **Zefling** » 15 août 2009, 14:02

Kazé a écrit :
Zefling a écrit :Indenté avec la coloration, ça va.
En bordel sans coloration,... heu...
L’onglet « Source » est le cadet de mes soucis à l’heure actuelle. Je bosserai dessus quand la vue splittée sera au point, pas avant.

Bha, vire-le. Il vaut mieux ne rien mettre plutôt que de s'encombrer d'un truc inutilisable. En plus, ça va desservir Kompozer en l'état.

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

Kazé · Message par **Kazé** » 15 août 2009, 15:55

pascalmac78 a écrit :J'en ai été un utilisateur plutôt assidu ces dernières années, mais je l'utilise maintenant de moins en moins depuis que je travaille sous XHTML. J'ai pu remarquer que l'utilisation de Komposer rendait les pages non valides W3C (erreurs de syntaxe principalement (<br>, ...).
C'est un grand regret, et je suis attentif à toute évolution permettant de nouveau de retravailler avec Komposer, sous XHTML ou les standards à venir.

Oui, le support XHTML sera l’un des gros morceaux de la phase bêta.

Ymai a écrit :On vote où pour que cet onglet re-disparaisse? Au moins momentanément.
Pas la peine de se mettre la pression là-dessus alors que la vue "split" me paraît largement suffisante, voire bien supérieure.

Il est à peu près évident que je préfèrerais ne pas avoir d’onglet « Source » du tout plutôt que celui-là, ou pire, celui de Nvu.

Et oui, la vue splittée est largement supérieure techniquement, malgré ses bugs de jeunesse. Elle apporte déjà deux avantages :

on peut l’utiliser au clavier : le curseur ne reste jamais coincé, comme c’est le cas parfois avec l’onglet « Source » de Nvu ;
elle affiche le *vrai* code HTML de l’élément pointé — y compris les espaces — et non une vue bricolée, comme dans l’onglet « Source » de Nvu (cf. les numéros de ligne annoncés par Nvu qui ne correspondent absolument pas à la réalité, entre autres exemples).

Une fois que cette vue splittée sera au point, j’utiliserai son composant d’édition de code pour remplacer l’onglet « Source ».
On pourrait ainsi envisager de garder la barre d’onglets de KompoZer en mode « Source », et peut-être même indenter le code source avec Tidy, voire éditer des fichiers de code (JavaScript, CSS, PHP, Ruby, htaccess…) en utilisant le Lexer de Scintilla.

Chaque chose en son temps. Pour des raisons tant pratiques que techniques, l’onglet « Source » sera la toute dernière étape du développement de KompoZer 0.8.

Zefling a écrit :Bha, vire-le. Il vaut mieux ne rien mettre plutôt que de s'encombrer d'un truc inutilisable.

J’ai mis cet onglet « Source » justement parce que j’en avais marre de recevoir 50 mails par jour me demandant de le remettre.
Vous l’avez voulu, vous l’avez !

Mais rien n’oblige à l’utiliser pour autant, d’autant qu’il ne sera pas conservé en l’état pour la version 0.8 finale.

Message envoyé avec : Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

Geckozone

KompoZer 0.8 alpha4

http://www.htmlcodetutorial.com/images/_IMG_ALIGN.html

Problème Komposer

Re: Problème Komposer

Qui est en ligne ?