[KompoZer 0.8] Portage de KompoZer sous Gecko 1.8.1

[Deepsco]

Voici quelques observations
Lors de l'insertion de photo, dans la fenêtre apparition d'une mention en rouge <menuitem accesskey= »&releasCmd. Accesskey; »-----^
Impossible de modifier la largeur des tableaux insérés. Le seul repère apparaissant dans la barre d'attribut (sous l'onglet de la page, ne correspond à rien.
Pas d'acceptation du langpack FR
Par contre pas de problème avec la la barre d'état.
Voilà ce que j'ai pu observer brièvement.

Message envoyé avec : Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.0.4) Gecko/2008111318 Firefox/8.10 (intrepid) Firefox/3.0.4

[Ymai]

Rhaaaa et pourtant chez moi ça fonctionne.
J’ai supprimé mon profil, téléchargé l’archive, dézippé, lancé, et ça a marché.

Ayé. Je l'ai retéléchargé et ça marche.

[Ymai]

Génial le dock.
Du point de vue didactique, on va pouvoir aller loin avec ça.

Je n'aurai pas beaucoup de temps pour tester, ce week-end. Ou alors vraiment pour me défouler.
Un petit truc un peu déstabilisant pour l'utilisateur lambda:
je clique sur une balise dans la barre d'état et il me vient, dans le dock, toutes sortes de styles liés à la mise en évidence des éléments sur la page.
Le souci n'est pas là quand on utilise le block outline.

J'ai un message d'erreur dans la fenêtre du Snap To Grid (menu Format):
<menuitem accesskey="&releasedCmd.accessKey;".
Puis, la fonction n'a pas l'air de fonctionner.
C'est nouveau?

[Kazé]

Pour le coup du

Code : Tout sélectionner

 <menuitem accesskey="&releasedCmd.accessKey;" 

qui apparaît dans les boites de dialogue « image » et « snap to grid », c’est une régression, à corriger.
Il y a peut-être d’autres régressions du même genre, vu que je suis reparti du code de Firefox 2.0.0.18 pour cette version.

Suite à vos remarques, je suis en train de faire quelques corrections.
Notamment, je vais rétablir le fait qu’un clic sur un bouton de la barre d’état sélectionne l’élément au lieu de se contenter d’en afficher le code HTML. On pourra afficher le code sans sélectionner l’élément avec un clic molette.
Je vais aussi faire en sorte que quand on fait un Alt+Enter ça soit systématiquement le code affiché dans le dock qui soit édité (actuellement ce n’est pas toujours le cas).

Sinon, que pensez-vous de l’affichage d’une bordure autour de l’élément quand on survole le bouton correspondant dans la barre d’état ? Utile ou pas ? Insuffisant ? Confusant ?
Toujours dans les considérations ergonomiques, j’ai essayé de faire en sorte que le dock soit utilisable sans toucher la souris, d’où :

• le raccourci Alt+Enter pour basculer entre les modes visu / édition
• les raccourcis Alt+flèches pour séléctionner l’élément suivant / précédent / parent / enfant.

Là encore, est-ce utile ou pas ? Ou plutôt (vu que c’est déjà codé) : est-ce gênant si je le laisse ?

Dans le même ordre d’idée : dans la nouvelle barre d’état, on peut aussi sélectionner l’élément précédant/suivant en jouant avec la molette. Ça marchouille sur la version que vous avez, ça fonctionne mieux sur ma version de travail.

[Ymai]

Suite à vos remarques

Heuuuhhh...???

je vais rétablir le fait qu’un clic sur un bouton de la barre d’état sélectionne l’élément au lieu de se contenter d’en afficher le code HTML.

S'il n'est pas possible d'avoir juste le code sec...

On pourra afficher le code sans sélectionner l’élément avec un clic molette.

Le clic molette est-il vraiment entré dans les moeurs? Sauf pour le copier/coller dans une console, j'avoue que...

Je vais aussi faire en sorte que quand on fait un Alt+Enter ça soit systématiquement le code affiché dans le dock qui soit édité (actuellement ce n’est pas toujours le cas).

C'est gé-nial!!! Super-grandissime, ce alt-Enter.

Sinon, que pensez-vous de l’affichage d’une bordure autour de l’élément quand on survole le bouton correspondant dans la barre d’état ? Utile ou pas ?

[mode Luchini ON]C'est énooooorme[mode Luchini OFF]

Insuffisant ? Confusant ?

C'est vrai: comment dit-on "confusing" in french?

Toujours dans les considérations ergonomiques....Ou plutôt (vu que c’est déjà codé) : est-ce gênant si je le laisse ?

Là, maintenant, tout de suite, je n'en vois pas bien l'utilité. Mais pourquoi enlever ce qui pourrait devenir une killing feature?

Dans le même ordre d’idée : dans la nouvelle barre d’état, on peut aussi sélectionner l’élément précédant/suivant en jouant avec la molette. Ça marchouille sur la version que vous avez,

Chez moi, ça marche bien. Dommage que ça ne concerne que le dock et pas le contenu de l'onglet "Normal"

Pour le reste, j'avoue que j'en reste bouche bée. Grandiose travail.

[Kazé]

Suite à vos remarques

Heuuuhhh...???

Je faisais référence aux règles de style qui sont ajoutées inopinément dans le dock source. Pour résoudre ce bug je m’aperçoit qu’il faut répondre à des questions existentielles du genre : un clic gauche dans la barre d’état doit-il sélectionner l’élément ou uniquement en afficher le code HTML ? La molette sur un bouton de la barre d’état doit-elle sélectionner l’élément précédant/suivant ou juste en afficher le code ? Comment va-t’on éditer le contenu de <head> ? Etc.

Je crois qu’on n’aura les réponses qu’à l’usage, pour l’instant je teste différentes possibilités. Le code de ce dock et de la nouvelle barre d’état est très simple (~500 lignes de JavaScript), donc facilement modifiable.

C'est vrai: comment dit-on "confusing" in french?

Boxogène ?
Blague à part, je veux éviter de rendre l’interface trop complexe et je tiens à ce que ça soit utilisable au clavier.
La navigation au clavier pose parfois problème dans KpZ, les Alt+flèches sont là en partie pour y remédier — et aussi parce que je trouve pratique de faire un Alt+gauche, Alt+Entrée pour éditer le code HTML de l’élément parent. Le Alt+Backspace, Backspace permet de supprimer proprement un élément au clavier. Reste à savoir si c’est documentable (un autre barbarisme)…
En tout cas, le Alt+Entrée mériterait une ligne dans le « tip of the day ».

[Kazé]

Ayé, je peux éditer le <head> dans ma version de travail, ce qui m’a permis de tomber sur un très joli bug (peut-être déjà signalé ?) :

• ouvrir une page (html, xhtml, qu’importe)
• ouvrir l’éditeur CSS
• annuler

=> les feuilles de style ne sont plus reconnues, et ce, bien qu’elles apparaissent dans le <head>.

[chinon37]

Après quelques tests rapides ce jour d'hui:
en vrac (fidèle à moi-même ):
alt+ flèches directionnelles et alt+ enter: j'aime beaucoup. C'est très rapide (et je suis un adepte des raccourcis clavier....).Chez moi, le alt+enter semble très bien marcher
Je ne comprends pas très bien le ctrl+clic molette qui met un :

Code : Tout sélectionner

<blockquote type="cite">http://www.google.fr/</blockquote>

ce coup ci, c'est http://www.google.fr/ qui s'est mis après le blockquote, sans que je comprennes pourquoi (il n'était pas en mémoire de copie?!), mais le

Code : Tout sélectionner

<blockquote type="cite">***</blockquote>

se met systématiquement : c'est volontaire?
Le cadre sur l'élément survolé : ok pour moi

Un truc qui me perturbe: Je suis dans un paragraphe en wysiwyg (<html> <body> <div> <p>) Je sélectionnes body dans la barre d'état, c'est donc tout body qui s'affiche en mode source. je veux rentrer dans le code source pour ajouter une balise en mode édition > alt + entrée > c'est uniquement le code du <p> qui s'affiche et non tout le <body>.(i.e. là où j'étais au départ)
Avant, un clic sur une balise de la barre d'état sélectionnait cet élément et cachait dans la barre d'état les éléments enfants - je préférais...

Pas eu le temps de tester plus avant, mais au risque de paraphraser Ymai, je dirais que tu as fait un grand bon en avant - génial, bravo et merci!

[edit] y a-t-il une possibilité de garder la coloration syntaxique en "édition"?

Message envoyé avec : Mozilla/5.0 (X11; U; Linux x86_64; fr; rv:1.9.0.4) Gecko/2008111318 Ubuntu/8.04 (hardy) Firefox/3.0.4

[Kazé]

Je ne comprends pas très bien le ctrl+clic molette qui met un :

Code : Tout sélectionner

<blockquote type="cite">http://www.google.fr/</blockquote>

Sous Linux, clic molette = coller le contenu du presse-papier.
Le Ctrl+clic molette colle dans un élément <blockquote>, pourquoi pas. Ce raccourci est hérité de Mozilla Composer, il était déjà présent dans Nvu, mais je ne l’avais jamais vu jusqu’ici.

Un truc qui me perturbe: Je suis dans un paragraphe en wysiwyg (<html> <body> <div> <p>) Je sélectionnes body dans la barre d'état, c'est donc tout body qui s'affiche en mode source. je veux rentrer dans le code source pour ajouter une balise en mode édition > alt + entrée > c'est uniquement le code du <p> qui s'affiche et non tout le <body>.(i.e. là où j'étais au départ)

Oui, c’est un bug, et c’est corrigé sur ma version de travail.

Avant, un clic sur une balise de la barre d'état sélectionnait cet élément et cachait dans la barre d'état les éléments enfants - je préférais...

À l’usage, moi aussi je préfère sélectionner un élément avec un simple clic gauche. Pas simple de garder ce comportement *ET* la fonctionnalité de mise en évidence du bloc survolé.
[EDIT] On peut sélectionner l’élément courant avec Alt+Backspace ou un autre élément avec un clic droit > select dans la barre d’état, mais ça ne me convient pas non plus. [/EDIT]

y a-t-il une possibilité de garder la coloration syntaxique en "édition"?

Y’aurait plusieurs façons de le faire :

• réimplémenter un équivalent de l’onglet Source de Nvu : vue wysiwyg d’un code colorisé.
  Outre les problèmes de stabilité, outre le fait que la coloration syntaxique n’est pas temps réel, c’est incompatible avec l’édition en « dock » car on ne peut afficher qu’un seul composant d’édition wysiwyg par fenêtre.
• utiliser Firebug ou Diavolo (= l’équivalent BlueGriffon de Firebug, moins puissant et plus lent).
  Possible bien que moins immédiat à coder que ce dock source. Par contre, ce n’est pas utilisable au clavier, il faut une main sur la souris en permanence. Par ailleurs, la réactivité en prend un coup. Donc pour moi ça serait plutôt l’objet d’une extension.
• utiliser SciMoz, i.e. le composant Scintilla d’OpenKomodo.
  C’est la seule bonne façon de le faire, et c’est une des raisons pour lesquelles je pense qu’un éditeur ouèbe *doit* se baser sur OpenKomodo.

Donc la réponse courte, c’est « pas pour l’instant ».
Je suis conscient du fait que c’est une limite, mais j’ai fait ce choix d’architecture logicielle pour deux raisons :

• ça me facilitera le boulot quand il s’agira de porter KompoZer sur OpenKomodo
• je pourrais faire un KompoZer « light » qui reposerait sur ce principe… sous la forme d’une simple extension Firefox.

L’absence de coloration syntaxique ne me gêne pas outre mesure, puisqu’on n’a qu’un petit bout de code à éditer — souvent une seule ligne.

[chinon37]

L’absence de coloration syntaxique ne me gêne pas outre mesure, puisqu’on n’a qu’un petit bout de code à éditer — souvent une seule ligne.

C'était une simple question, mais ça ne pose pas problème pour l'instant, surtout si je sais que ça viendra un jour

chinon37 a écrit:
Avant, un clic sur une balise de la barre d'état sélectionnait cet élément et cachait dans la barre d'état les éléments enfants - je préférais...
À l’usage, moi aussi je préfère sélectionner un élément avec un simple clic gauche. Pas simple de garder ce comportement *ET* la fonctionnalité de mise en évidence du bloc survolé.
[EDIT] On peut sélectionner l’élément courant avec Alt+Backspace ou un autre élément avec un clic droit > select dans la barre d’état, mais ça ne me convient pas non plus. [/EDIT]

on ne se défait pas facilement de ses habitudes!!!

[chinon37]

Petite régression dans l'affichage de l'éditeur css au niveau des boutons de taille: ils sont devenus minuscules...

[Ymai]

[*] annuler[/list] => les feuilles de style ne sont plus reconnues, et ce, bien qu’elles apparaissent dans le <head>.

C'est sans doute le bug que j'ai rapporté en son temps. A l'époque où j'avais passé une longue après-midi à modifier la feuille de style de mon site web. C'était superbe.
Presque terminé, j'enregistre encore une fois (comme je faisais toutes les 5 minutes, depuis quelques heures). Et puis, tout à coup, retour à mes styles du début d'après-midi. Tout perdu.

C'est également un bug plusieurs fois observé en cours. Une heure de travail perdue.
Donc, s'il est trouvé (et qu'il est possible de le corriger), je pousse un rugissant yabadabadooooooo....

[Kazé]

C'était une simple question, mais ça ne pose pas problème pour l'instant, surtout si je sais que ça viendra un jour

La question n’est pas anodine, du moins pour moi. Elle a des répercussions fondamentales sur l’architecture logicielle du projet.
J’ai acquis beaucoup plus de doutes que de certitudes avec le projet KompoZer. Mais s’il y a bien *UNE* certitude que j’en ai tirée, c’est qu’un éditeur ouèbe doit se baser sur le texte et non sur l’arbre DOM. Donc oui, ça viendra : pour moi, tout éditeur ouèbe basé *uniquement* sur l’abre DOM comme Nvu, KpZ ou BlueGriffon est voué à l’échec.
Un bon éditeur ouèbe est avant tout un bon éditeur texte. Ça parait idiot mais ça fait désormais partie de mes certitudes.

Utiliser l’arbre DOM pour sélectionner des éléments à coups de Alt+Flèches ou faire du CSS, oui. Pour générer du HTML et intégrer du PHP, ça ne marchera jamais, quel que soit le nombre de rustines qu’on applique au code (et ce n’est pas qu’une question de coloration syntaxique). D’où ma certitude qu’il faut baser KompoZer sur Komodo, et non sur Firefox.

C'est sans doute le bug que j'ai rapporté en son temps.

Possiblement. L’annulation des modifications sur les règles de style passe par la réactualisation du nœud <head>, et force m’est d’admettre que cette méthode n’est pas 100% sûre, loin s’en faut — la preuve avec le noyau 1.8.1.

[chinon37]

A l'époque où j'avais passé une longue après-midi à modifier la feuille de style de mon site web. C'était superbe.

On ne demande qu'à te croire

[arnaudj]

Juste un message rapide pour dire que le travail de Kazé est TRÈS apprécié ! Vraiment, merci 1000 fois !

Message envoyé avec : Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.0.4) Gecko/2008111318 Ubuntu/8.10 (intrepid) Firefox/3.0.4