[KompoZer 0.8] Portage de KompoZer sous Gecko 1.8.1

[chinon37]

Oulala, y'a du vieux profil dans l'air... avec des extensions...

Pour l'instant, il ne faut pas d'extensions.

[Ymai]

Cette copie d'écran peut servir à illustrer ma version Linux.

Mais pas du tout!! Vous n'auriez pas un reste de profil qui traîne?

Message envoyé avec : Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.6) Gecko/2009020911 Ubuntu/8.04 (hardy) Firefox/3.0.6

[Zefling]

Bha j'ai ma 0.7 d'installée.

Comment je peux lancer la 0.8 avec un nouveau profil ? (j'ai pas envie de virer celui de la 0.7 je m'en sers tout le temps).

Édit :

Code : Tout sélectionner

kompozer.exe -p 

J'aurais du y penser plus vite. Ça marche effectivement beaucoup mieux avec un profil de test vierge.

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6

[Zefling]

L'arbre des DOM il va rester comme ça où il va finir comme celui de firebug (qui est beaucoup plus souple) ?

La fenêtre « Advanced Property Editor », j'ai toujours tout fait pour ne pas l'utiliser tellement elle est chiante. J'ai l'impression d'utiliser l'IDE de Flash 4.

Dans CSS Stylesheets, les onglets ont un fonctionnement bizarre. Il faut faire un drag'n drop dessus car un simple clic dessus renvoi sur Général.

Sinon, il y a toujours le problème des liens qui restent noirs.

Ctrl+ ] : ne fonctionne toujours pas non plus :p

Les tableaux ne le font plus planter (je peux en faire... même si je m'en suis bien passé jusque là, mais parfois ça sert quand il faut faire un tableau). Par contre on peut faire un tableau sans cellule en faisant un peu n'importe quoi

Le volet qui se trouve en dessous présente le contenu d'un nœud (c'est très bien), mais il y aurait pas le moyen de le rendre éditable. Genre : cliquer sur un des éléments permet d'ajout une classe ou un id (comme dans firebug) ?


Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6

[Mongo Bob]

Mais pas du tout!! Vous n'auriez pas un reste de profil qui traîne?

Oui oui je vous entends tous très bien, or dans Linux, le profil est dans home/login/kompozer, ben pas chez moi. En +, aucune extension d'installée.

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6

[Kazé]

Juste pour info : les rapports de bogues viennent quasiment tous de Geckozone — et ce n’est pas faute d’avoir pris contact avec les autres forums Nvu/KompoZer. Sans vous, le projet KompoZer n’existerait pas.

L'arbre des DOM il va rester comme ça où il va finir comme celui de firebug (qui est beaucoup plus souple) ?

Plus précisément ?
Tu parles peut-être de l’arbre CSS dans le panneau DOM ?

La fenêtre « Advanced Property Editor », j'ai toujours tout fait pour ne pas l'utiliser tellement elle est chiante. J'ai l'impression d'utiliser l'IDE de Flash 4.

Mouais, je ne suis pas loin d’être d’accord, mais malheureusement je n’ai pas beaucoup d’idées pour faire mieux que ça. Si tu as des idées d’interface à proposer, lâche-toi.

Dans CSS Stylesheets, les onglets ont un fonctionnement bizarre. Il faut faire un drag'n drop dessus car un simple clic dessus renvoi sur Général.

En fait ces onglets sont censés être désactivés tant que tu n’as pas sélectionné une règle de style dans l’arbre de gauche : avec ton glisser-déplacer tu ne fais que contourner cette « désactivation ». Ça va bientôt être corrigé.

Le volet qui se trouve en dessous présente le contenu d'un nœud (c'est très bien), mais il y aurait pas le moyen de le rendre éditable. Genre : cliquer sur un des éléments permet d'ajout une classe ou un id (comme dans firebug) ?

On peut l’éditer en double-cliquant dedans, ou en faisant un Alt+Enter. On peut ajouter un id ou une classe avec un clic droit sur la barre d’état ou dans l’arbre DOM.

Pour ce qui est de l’interface, il y a effectivement un choix à faire. Je vois trois possibilités :

1. soit on présente le code de tout le nœud HTML, par exemple <h2> Easy Web Authoring </h2> — c’est ce qui est implémenté aujourd’hui
2. soit on ne présente que le contenu du nœud HTML, l’élément lui-même et ses attributs étant affichés dans une ligne au-dessus — un peu comme Firebug
3. variante de la solution précédente : on ne présente que le contenu du nœud HTML dans le dock, le nom de la balise HTML est affiché dans une ligne au-dessus, et les attributs HTML sont affichés dans un tableau genre « advanced properties » ou panel Firebug à droite.

Pour l’instant je suis parti sur la première option car je la trouve plus simple, plus didactique et plus pratique pour ajouter des attributs (du moins, pour ceux qui tapent vite et connaissent le nom des attributs HTML sur le bout des doigts). Accessoirement elle a été assez immédiate à coder. Par contre, elle n’est pas bien adaptée pour l’affichage des éléments <html>, <head> et <body>, dont on ne peut éditer que le contenu : ça casse un peu la cohérence de l’interface.

Depuis j’ai dû bosser sur le code de ce dock source, aujourd’hui je pourrais implémenter facilement la solution #2 et relativement facilement la solution #3. Il faut voir si le jeu en vaut la chandelle, en clair : pensez-vous que ça serait vraiment mieux ? J’avoue ne pas l’avoir fait car ça augmente sensiblement la taille du dock source, qui ne contient généralement pas grand-chose, et je crains que ça ne complique sensiblement l’interface pour le public visé par KompoZer. Si vous avez une opinion sur la question…

J’ai pensé ajouter les attributs HTML dans le panneau DOM, mais très sincèrement je ne crois pas que ça en vaille la peine : je modifie rarement des attributs HTML autres que id et class, et quand on doit toucher aux attributs HTML, on a déjà pas mal de possibilités : dock source, « advanced properties », fenêtre de propriétés de l’élément. Donc je dirais que si on veut ajouter les attributs HTML quelque part, c’est dans le dock source ou nulle part.

Enfin, une dernière alternative serait de garder la solution #1 en ajoutant le clic droit des boutons de la barre d’état, i.e. les menus id, class, remove tag, inline styles, advanced properties.

[Kazé]

Oui oui je vous entends tous très bien, or dans Linux, le profil est dans home/login/kompozer, ben pas chez moi. En +, aucune extension d'installée.

tu as peut-être oublié le point (.) devant « kompozer ». Le détail a son importance, puisque sous Linux les fichiers dont le nom commence par un point sont cachés.
Dans ton explorateur de fichiers (Nautilus ?) vérifie que tu as bien choisi d’afficher les fichiers cachés, ton dossier « home » en est nécessairement farci : les dossiers cachés du « home » correspondent plus ou moins aux dossiers d’« Application Data » sous Windows.

[Ymai]

Code : Tout sélectionner

kompozer.exe -p 

Et pour les dresseurs de manchots, hérons ou bouquetins:

Code : Tout sélectionner

./kompozer -ProfileManager

Message envoyé avec : Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.6) Gecko/2009020911 Ubuntu/8.04 (hardy) Firefox/3.0.6

[Mongo Bob]

>Kazé
right, chief!
bien vu fallait cocher "Afficher les dossiers cachés"
>chinon : bien que ce soit peut-être mettre les points sur les "i" juste à l'intention des gros nazes comme moi (la majorité discrète et humble, quoi), je propose d'ajouter éventuellement la précision

• de cocher dans Affichage/Afficher les dossiers cachés dans Linux
• de cocher dans Outils/Options des dossiers/Affichage/Afficher les fichiers et dossiers cachés dans Win.

dans le fameux post-it " Pourquoi choisir KompoZer plutôt que Nvu + Téléchargement"/post du 1/09/07 : "Je n'ai pas lu la doc ci-dessus, KompoZer plante au démarrage :", merci.

Et pour les dresseurs de manchots, hérons ou bouquetins:
Code:
./kompozer -ProfileManager

noté, donc.
Message envoyé avec : Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.0.5) Gecko/2008121622 Ubuntu/8.10 (intrepid) Firefox/3.0.5

[Mongo Bob]

>Ymai :
je l'ai supprimé manuellement, vu que :

Code : Tout sélectionner

root@jlsubuntu:~# ./kompozer -ProfileManager
bash: ./kompozer: Aucun fichier ou dossier de ce type
root@jlsubuntu:~# 

pas grave
<edit>Ah, mais! Ca va beaucoup beaucoup mieux :

merci à tous...</edit>
Message envoyé avec : Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.0.5) Gecko/2008121622 Ubuntu/8.10 (intrepid) Firefox/3.0.5

[Ymai]

>Ymai :
je l'ai supprimé manuellement, vu que :

Code : Tout sélectionner

root@jlsubuntu:~# ./kompozer -ProfileManager
bash: ./kompozer: Aucun fichier ou dossier de ce type
root@jlsubuntu:~# 

pas grave

Attention!!
Ne pas confondre le répertoire .kompozer qui se trouve dans ton /home
et l'exécutable
kompozer
qui se trouve dans un répertoire quelconque. Peut-être /home/kompozer ou /opt/kompozer ou /usr/bin/kompozer...
Pour démarrer KompoZer en console, se placer dans ce répertoire
$ cd /home/kompozer
(par exemple)
et frapper la commande
./kompozer
qui lance l'exécutable kompozer qui se trouve dans le répertoire courant (le répertoire "." )
le "./" sert à indiquer le chemin vers l'exécutable. C'est une règle que d'indiquer le chemin pour tous les exécutables qui ne se trouvent pas dans un des répertoire du PATH

Code : Tout sélectionner

$ echo $PATH

Dans le cas présent, tu n'étais visiblement pas dans le répertoire qui contient l'exécutable kompozer.
Conseil en passant: ne pas travailler en "root" quand ce n'est pas strictement nécessaire.

[edit HS]J'ai été chatouiller le forum en anglais et un forum en néerlandais histoire de les faire bouger. Quelqu'un peut placer un avis sur le forum italien qui a quand même l'air au courant?
http://forum.mozillaitalia.org/index.php?topic=37401.0 [/edit]

Message envoyé avec : Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.6) Gecko/2009020911 Ubuntu/8.04 (hardy) Firefox/3.0.6

[Zefling]

L'arbre des DOM il va rester comme ça où il va finir comme celui de firebug (qui est beaucoup plus souple) ?

Plus précisément ?
Tu parles peut-être de l’arbre CSS dans le panneau DOM ?

Oui c'est bien celui là.
Celui de composeur ne fait qu'afficher les nœuds, mais serait bien de ne pas mettre que les nœuds car quand le document commence à être complexe, pour retrouver rapidement tellement ayant un classe ou un id c'est assez galère. D'ailleurs j'ai fais une petit test où j'imbrique plein éléments au bout d'un moment je commence à m'y perdre sans repère.

Code : Tout sélectionner

div 
+ div 
  + div 
    + div 
      + div 
        + div 
          + div 

Pas facile de comprend à quoi sert quoi sans les classes ou les ids.
Avec Firebug ça donne ça :

Code : Tout sélectionner

<div id="conteneur">
  <div class="s_conteneur">
    <div class="corps">
      <div class="menu_gauche">
         <div class="menu_cadre">
            <div class="menu_cadre_titre_1">

Comme ça c'est quand même plus lisible.

La fenêtre « Advanced Property Editor », j'ai toujours tout fait pour ne pas l'utiliser tellement elle est chiante. J'ai l'impression d'utiliser l'IDE de Flash 4.

Mouais, je ne suis pas loin d’être d’accord, mais malheureusement je n’ai pas beaucoup d’idées pour faire mieux que ça. Si tu as des idées d’interface à proposer, lâche-toi.

Je vais y réfléchir. C'est coton si on veut contenante tout le monde. Mais j'avoue que ça forme actuelle n'est pas terrible parce qu'elle ne fourni pas assez d'aide pour la contrainte qu'elle impose. Pas d'auto-complession pour le CSS par exemple. Je connais bien un grand majorité des commandes mais les background-image c'est chiant à taper en entier (en plus faut pas faire de fautes d'inattention ).
Le fait de ne pas pouvoir directement éditer les champs qui sont dans les listes, c'est ça que je déteste. On le sélection, on repasse en bas on modifie, puis on remonte dans la liste... Un va et vient contraignant. Alors que ça pourrait être fait directement. Supprimer avec [suppr.] au lieu du bouton remove.
En fait je virerais tout la partie du bas du formulaire pour tout mettre dans le liste. Avec des [Tab] pour naviguer entre les éléments.

Dans CSS Stylesheets, les onglets ont un fonctionnement bizarre. Il faut faire un drag'n drop dessus car un simple clic dessus renvoi sur Général.

En fait ces onglets sont censés être désactivés tant que tu n’as pas sélectionné une règle de style dans l’arbre de gauche : avec ton glisser-déplacer tu ne fais que contourner cette « désactivation ». Ça va bientôt être corrigé.

J'essaie de comprendre à quoi ça sert
J'espère que c'est pas le trucs pour écrire les feuilles de style

Le volet qui se trouve en dessous présente le contenu d'un nœud (c'est très bien), mais il y aurait pas le moyen de le rendre éditable. Genre : cliquer sur un des éléments permet d'ajout une classe ou un id (comme dans firebug) ?

On peut l’éditer en double-cliquant dedans, ou en faisant un Alt+Enter. On peut ajouter un id ou une classe avec un clic droit sur la barre d’état ou dans l’arbre DOM.

J'avais pas vu ça. Ça fait mode expert c'est ce que je cherchais. Le Alt+Enter correspond au double clic sur une nœud dans Firebug.

« d'ajout une classe ou un id (comme dans firebug) », c'est sur l'arbre que ça se fait dans firebug. Et c'est pas plus mal. Mais si c'était dans le deux ça serait aussi bien. Je doute que ça doit demander un gros boulot.

Pour ce qui est de l’interface, il y a effectivement un choix à faire. Je vois trois possibilités :

1. soit on présente le code de tout le nœud HTML, par exemple <h2> Easy Web Authoring </h2> — c’est ce qui est implémenté aujourd’hui
2. soit on ne présente que le contenu du nœud HTML, l’élément lui-même et ses attributs étant affichés dans une ligne au-dessus — un peu comme Firebug
3. variante de la solution précédente : on ne présente que le contenu du nœud HTML dans le dock, le nom de la balise HTML est affiché dans une ligne au-dessus, et les attributs HTML sont affichés dans un tableau genre « advanced properties » ou panel Firebug à droite.

Pour l’instant je suis parti sur la première option car je la trouve plus simple, plus didactique et plus pratique pour ajouter des attributs (du moins, pour ceux qui tapent vite et connaissent le nom des attributs HTML sur le bout des doigts). Accessoirement elle a été assez immédiate à coder. Par contre, elle n’est pas bien adaptée pour l’affichage des éléments <html>, <head> et <body>, dont on ne peut éditer que le contenu : ça casse un peu la cohérence de l’interface.

Depuis j’ai dû bosser sur le code de ce dock source, aujourd’hui je pourrais implémenter facilement la solution #2 et relativement facilement la solution #3. Il faut voir si le jeu en vaut la chandelle, en clair : pensez-vous que ça serait vraiment mieux ? J’avoue ne pas l’avoir fait car ça augmente sensiblement la taille du dock source, qui ne contient généralement pas grand-chose, et je crains que ça ne complique sensiblement l’interface pour le public visé par KompoZer. Si vous avez une opinion sur la question…

J’ai pensé ajouter les attributs HTML dans le panneau DOM, mais très sincèrement je ne crois pas que ça en vaille la peine : je modifie rarement des attributs HTML autres que id et class, et quand on doit toucher aux attributs HTML, on a déjà pas mal de possibilités : dock source, « advanced properties », fenêtre de propriétés de l’élément. Donc je dirais que si on veut ajouter les attributs HTML quelque part, c’est dans le dock source ou nulle part.

Enfin, une dernière alternative serait de garder la solution #1 en ajoutant le clic droit des boutons de la barre d’état, i.e. les menus id, class, remove tag, inline styles, advanced properties.

C'est vrai que présenté comme ça.
Pour le doc je m'en sert pas dans firebug par ce qu'il faudrait que je 3200×2400 pour le voir entier, trop d'information et ça déborde vite de l'écran. Dommage qu'il ne soit pas sur plusieurs lignes, parfois.

La présentation actuel #1 ressemble à un mélange de la vu avancé avec la coloration syntaxique. C'est sympa tant qu'il n'y a pas trop de contenu dans le nœud. De plus j'ai l'impression d'édition demander beaucoup de resource (quand j'ai testé je me suis retrouvé avec un 100% CPU).
#3 & #2 je sais pas trop...

La solution de montrer classe et id présente beaucoup plus de clarté, même si les nœuds sont pas éditables, on voit clairement ce que l'on touche. (comme je le montre plus haut).
Si la solution à pour but de modifier rapidement la mise en forme le pense qu'un panel qui ressemble à Style & Apparence s'impose. Pour être franc c'est principalement eux que j'utilise. Sauf que la partie Style de Firebug est là pour faire des corrections en directe qui ne sont pas sauvé. Pas possible d'ajouter des règles directement dedans (mais on peut le faire pas l'onglet CSS). Il faudrait voir.

Quand on fait de l'édition pour la mise en page les deux points important sont :
* L'édition facile du HTML (normalement le wysiwig est là pour ça) avec l'aide le mode d'avancer (qui est très bien comme tu l'as fait, enfin avec la coloration syntaxique pour éviter les erreurs bêtes ça serait mieux)
* L'édition du CSS (la plus simple et la plus rapide). Le principe de Firebug me plait beaucoup parce qu'on peut annuler des règles sans les supprimer.

Pour moi le Javascript c'est ça vient après. J'utiliserais plus Firebox pour ça parce qu'avec l'AJAX ça complique un peu trop les choses dans KompoZer.

Dans CSS Rules quelque chose est prévu ?



En tout cas, si quelqu'un d'autre que moi à son idée ça serait mieux. Il faudrait d'autre avis. Je présente un peu trop mon utilisation personnelle qui est probablement différents d'autres.

D'ailleurs c'est un peu le reproche qu'on peut faire à Firebug, à vouloir contenter tout le monde, c'est un peu une usine à gaz. Enfin tant que mon PC ne rame pas trop ça va. (Mais j'irais pas surfer avec) Cependant il faut admettre que même si il y a des trucs que je mets sert presque jamais, je suis parfois bien content que les options soient présentes.

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6

[chinon37]

J'ai sans doute loupé une étape:
on ne peut pas ouvrir une page php par un double clic à partir du gestionnaire de site? la page se lance dans le navigateur.
Il faut toujours avoir installé Nsmcontext? Ce n'est pas intégré?

[Kazé]

Zefling > l’arbre HTML devrait afficher les attributs id et class. Si ça ne s’affiche pas chez toi, il y a un problème — URL de ta page + rapport d’erreur JavaScript STP ?

Le fait de ne pas pouvoir directement éditer les champs qui sont dans les listes, c'est ça que je déteste. On le sélection, on repasse en bas on modifie, puis on remonte dans la liste... Un va et vient contraignant. Alors que ça pourrait être fait directement. Supprimer avec [suppr.] au lieu du bouton remove.
En fait je virerais tout la partie du bas du formulaire pour tout mettre dans le liste. Avec des [Tab] pour naviguer entre les éléments.

Il faut que je regarde si le noyau Gecko 1.8.1 me permet d’utiliser des tableaux éditables. Ça permettrait d’avoir des propriétés éditables de façon plus classique.

J'espère que c'est pas le trucs pour écrire les feuilles de style

Euh, si…
Pour l’instant il est un peu plus merdique que d’habitude à cause de l’absence des icones, mais ça reste un éditeur wysiwyg. Un sujet a été ouvert pour refaire l’interface de l’éditeur CSS : http://www.geckozone.org/forum/viewtopic.php?t=73038

Pas d'auto-complession pour le CSS par exemple.

Effectivement, et il n’y en aura pas tant que je n’aurai pas intégré un vrai composant d’édition de texte (Scintilla — d’où mon vieux rêve de baser KompoZer sur OpenKomodo). Ça viendra peut-être, mais pas pour la branche 0.8.x, désolé.
L’alternative serait de pomper le panneau CSS de Firebug, mais ça me plait moins car ça requiert des allers-retours clavier / souris — d’une manière générale, je trouve Firebug très bien pour le débug mais son interface me parait inadaptée à l’édition.
Pour l’instant, l’idée de l’éditeur CSS c’est de pouvoir ajuster les feuilles de styles à la souris, en wysiwyg. Je pourrais améliorer l’édition de propriétés CSS en utilisant des tableaux éditables, voir plus haut. Ça remplirait la même fonction que l’auto-complétion.

Quand on fait de l'édition pour la mise en page les deux points important sont :
* L'édition facile du HTML (normalement le wysiwig est là pour ça) avec l'aide le mode d'avancer (qui est très bien comme tu l'as fait, enfin avec la coloration syntaxique pour éviter les erreurs bêtes ça serait mieux)
* L'édition du CSS (la plus simple et la plus rapide). Le principe de Firebug me plait beaucoup parce qu'on peut annuler des règles sans les supprimer.

Personnellement je suis de l’avis inverse : ça ne me gêne pas d’éditer du HTML en mode texte, mais pour le CSS je préfère largement une interface wysiwyg.
Par contre, j’avoue que c’est pratique de pouvoir désactiver une règle de style dans Firebug, je regarderai si je peux implémenter ça sans trop alourdir l’interface. Ça pourrait faire l’objet d’une version 0.8.x.

La présentation actuel #1 ressemble à un mélange de la vu avancé avec la coloration syntaxique. C'est sympa tant qu'il n'y a pas trop de contenu dans le nœud. De plus j'ai l'impression d'édition demander beaucoup de resource (quand j'ai testé je me suis retrouvé avec un 100% CPU)

Oui, quand on veut afficher/éditer un gros élément HTML (ex : <body>), ça rame. Je peux optimiser un chouille mais ce dock restera malpratique pour éditer <body> ou <html>. Ça fait partie des raisons qui pourraient me conduire à réintroduire l’onglet « Source », sous une forme ou une autre.

D'ailleurs c'est un peu le reproche qu'on peut faire à Firebug, à vouloir contenter tout le monde, c'est un peu une usine à gaz.

+1
Ça fait partie des raisons pour lesquelles j’ai abandonné l’idée de porter Firebug sous KompoZer. Par ailleurs, je trouve que Firebug est trop complexe pour le public ciblé par KompoZer.

J'ai sans doute loupé une étape:
on ne peut pas ouvrir une page php par un double clic à partir du gestionnaire de site? la page se lance dans le navigateur.
Il faut toujours avoir installé Nsmcontext? Ce n'est pas intégré?

Ça, c’est la magie des fichiers *.php sous Linux, une sombre histoire de type MIME. C’est en installant HandCoder qu’on résoud le problème — NsmConTet n’est pas encore complètement intégré à KompoZer 0.8 mais c’est en cours.
Par contre, si tu as eu ce problème sous Windows, c’est gênant.

[chinon37]

Donc, c'est embêtant (oui, sous win)