Geckozone

Salut,

La question est simple. je me lance. Une tranche de rêve sur le mode wysiwyg de kpz, vous en avez une aussi, allez-y ! Les erreurs sont acceptées .

J'enlèverai toutes les barres d'outils. Je ne laisserai que les onglets des différents mode de vues (normal, balises HTML, aperçu et conception, mixte, source) afin d'avoir un vrai espace de travail..

Je réduirai toutes les commandes à trois commandes principales activées par les touches fonctions qui activent des fenêtres soit flottantes soit intégrées et une dernière pour la configuration.

• *F5, tout ce qui concerne la gestion du fichier (sa dtd, son entête, métadonnées avancées, option modèle, projet [projet, gestion et création des répertoires d'un site web : css, images, fichiers,etc].
  
  *F6, tout ce qui concerne la structure HTML et l'éditeur CSS rassemblés en deux onglets. Onglet structure (attribution des balises, en-dessous pour chaque balise accès direct à ses propriétés, attributs, style interne, javascript). Une option spéciale, la touche "s" pour sélection qui permet d'encadrer des balises comme la sélection dans gimp. Une fois la sélection confirmée, un conteneur générique est créé.
  Onglet CSS, l'éditeur CSS avec dans la fenêtre gauche un onglet supplémentaire pour la structure DOM.
  
  *F7, tout ce qui concerne la gestion FTP, local, distant et les aperçus dans différents navigateurs.
  
  *F8, la commande de configuration qui permet de déterminer le type d'utilisation de kpz, mode simple (pas d'accès à l'éditeur CSS) mais kpz gère tout. Mode avancé, là on a accès à l'éditeur CSS et toutes les autres commandes en lignes sont désactivées.

Et Voilà !

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

Et 20 développeurs sous la férule de Kazé qui codent, qui codent, qui codent.
Quelques danseuses orientales par là aussi... Peut-être.
En tous les cas, une caisse de Chimay Bleue à disposition et toujours pleine (la caisse).
Le soleil est trop fort aujourd'hui. Faut que je retourne à l'air-co.

Ymai a écrit : En tous les cas, une caisse de Chimay Bleue à disposition et toujours pleine (la caisse).

Je veux bien aider à remplir la caisse et à la vider aussi, mais pour l'instant, c'est l'arlésienne...

J’aime bien ce genre de discussions, malheureusement je vois que jmj n’a pas suscité l’enthousiasme.
Si j’ai bien suivi le propos, il y a deux aspects :

• avoir plus d’espace utile
• regrouper les propriétés par panneaux et/ou boites de dialogue

C’est vrai que je préférerais avoir moins de boites de dialogues et regrouper les propriétés dans des panneaux qui pourraient s’afficher

• soit comme panneau latéral (ex : quand on dispose d’un grand écran)
• soit comme une boite de dialogue (ex : netbook)

Coté code ça ne représente pas beaucoup de travail, mais par contre ça supposerait de repenser la disposition des éléments dans ces boites de dialogue, pour qu’elles puissent tenir dans un panneau latéral.

/jmj a écrit : J'enlèverai toutes les barres d'outils […] afin d'avoir un vrai espace de travail.
Je réduirai toutes les commandes à trois commandes principales activées par les touches fonctions qui activent des fenêtres soit flottantes soit intégrées et une dernière pour la configuration.

Les barres d’outils prennent trop de place, c’est un fait :

• la barre d’outils principale est trop grosse, même avec des « petites » icônes. Il faudrait que je prenne le temps de diminuer la taille des icônes.
• Dans les barres d’outils de mise en forme, la deuxième barre pourrait disparaître, ou au moins être désactivée par défaut — d’autant qu’elle est généralement utilisée de façon cradingue, ce qui aboutit à du code HTML irrécupérable.

Pour lever une éventuelle ambiguïté : je trouve qu’une barre d’outils « traditionnelle » c’est important. Ça fait partie des rares standards en ergonomie, il faut conserver ça.

/jmj a écrit : *F5, tout ce qui concerne la gestion du fichier (sa dtd, son entête, métadonnées avancées, option modèle, projet [projet, gestion et création des répertoires d'un site web : css, images, fichiers,etc].

Oui, je pense qu’il faut repenser le panneau « propriétés de la page » de toute façon : http://www.geckozone.org/forum/viewtopi ... 526#525526
N’hésite pas à proposer une maquette (GIMP, Inkscape…). Il n’y a pas de contrainte particulière, c’est le genre de chose qui peut très bien faire l’objet d’une boite de dialogue et qui n’aurait que peu d’intérêt en panneau latéral : ce n’est pas le genre de données qu’on modifie souvent.

/jmj a écrit : *F6, tout ce qui concerne la structure HTML et l'éditeur CSS rassemblés en deux onglets. Onglet structure (attribution des balises, en-dessous pour chaque balise accès direct à ses propriétés, attributs, style interne, javascript). Une option spéciale, la touche "s" pour sélection qui permet d'encadrer des balises comme la sélection dans gimp. Une fois la sélection confirmée, un conteneur générique est créé.
Onglet CSS, l'éditeur CSS avec dans la fenêtre gauche un onglet supplémentaire pour la structure DOM.

Là je crois qu’avec la DOM sidebar, on n’en est plus très loin.
La sélection type GIMP a été désactivée, mais elle cause un bug de focalisation sur l’ensemble de la fenêtre. C’est le genre de choses que je pourrais réimplémenter via une préférence.
Pour l’édition de nœuds HTML ou de propriétés de style : pour l’instant la DOM sidebar est en lecture seule mais c’est appelé à évoluer, bien évidemment.

/jmj a écrit :*F7, tout ce qui concerne la gestion FTP, local, distant et les aperçus dans différents navigateurs.

Si tu as des suggestions sur le gestionnaire de sites, c’est maintenant ou jamais, je suis dessus !!
Pour l’aperçu dans le navigateur, par contre, je pense qu’un bouton dans la barre principale saymieux (ou un raccourci clavier pour les plus pressés).

/jmj a écrit :*F8, la commande de configuration qui permet de déterminer le type d'utilisation de kpz, mode simple (pas d'accès à l'éditeur CSS) mais kpz gère tout. Mode avancé, là on a accès à l'éditeur CSS et toutes les autres commandes en lignes sont désactivées.

Pas sûr de te suivre là. Je pense au contraire qu’il faudrait faire en sorte de toujours passer par l’éditeur CSS, quitte à le faire « dans le dos de l’utilisateur ».

Un exemple-type de HTML pourri produit par KompoZer, c’est quand l’utilisateur a sélectionné toute la page (Ctrl+A ou clic sur <body>), puis choisi une police de caractère dans la deuxième barre d’outils de mise en forme :

• actuellement : KompoZer applique des <span> et des styles internes de partout, c’est l’horreur absolue pour maintenir un tel code ;
  ce qu’il faudrait : puisque toute la page est sélectionnée, KompoZer devrait créer automatiquement une feuille de style (ou la modifier, le cas échéant).

Dans le même ordre d’idée, on je pourrais créer un bouton « pinceau » comme dans OOo, qui servirait à copier la mise en forme de la sélection courante. Le scénario que j’imagine est le suivant :

1. l’utilisateur crée un superbe style pour des portions de texte, avec des couleurs, des bordures et des effets de polices aussi beaux qu’à Disneyland.
2. Il veut logiquement appliquer cette mise en forme à d’autres portions de texte : il double-clique sur le bouton « pinceau » ;
3. une boite de dialogue apparaît, lui demandant s’il veut appliquer le style à tous les éléments de même type (ex : titres, <em>, <b>), ou créer une classe (cf. le bouton « extraire et créer un style générique ») ;
4. le bouton « pinceau » est désormais « chargé » : il pourra sélectionner du texte dans la page, puis faire un simple clic sur le pinceau pour appliquer la mise en forme proprement.

Il faudrait probablement détailler plus, mais je pense que vous voyez le principe.

Mon opinion c’est que KompoZer sans éditeur CSS n’aurait ***aucun*** intérêt. Si les utilisateurs veulent créer des pages « comme avec Word », bah qu’ils utilisent Word ou OOo Writer, après tout on peut exporter en HTML. Je sais, c’est du HTML pourri, mais finalement guère plus que du code KompoZer dans ce cas-là.
Je pense que KompoZer doit au contraire rompre avec cette ergonomie, et proposer une utilisation de l’éditeur CSS qui soit aussi intuitive que possible.

Ymai a écrit :Et 20 développeurs sous la férule de Kazé qui codent, qui codent, qui codent.
Quelques danseuses orientales par là aussi...

Voilà, faudrait commencer par là.
D’ici là, si vous voulez proposer des maquettes d’interface (panneaux latéraux), ne vous gênez pas ! C’est surtout l’éditeur CSS que je voudrais bien passer en panneau latéral, quitte à devoir utiliser la barre de défilement et du pliage/dépliage de groupes de propriétés. Gardez quand même à l’esprit que ça ne serait pas pour KompoZer 0.8, mais pour une version ultérieure.

Message envoyé avec : Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.0.12) Gecko/2009070812 Ubuntu/8.04 (hardy) Firefox/3.0.12

Kazé a écrit :J’aime bien ce genre de discussions, malheureusement je vois que jmj n’a pas suscité l’enthousiasme.

Si, si, mais
1- il faut savoir prendre le temps de la réflexion
2- il y a des urgences : quelques chapitres à relire, ...
3- Il me faut maintenant lire et analyser toute ta prose, soit 2 pages d'écran
4- c'est les vacances, et pour ça, je n'ai même pô besoin de vent, moi

chinon37 a écrit :

Kazé a écrit :J’aime bien ce genre de discussions, malheureusement je vois que jmj n’a pas suscité l’enthousiasme.

Si, si, mais […]
Il me faut maintenant lire et analyser toute ta prose, soit 2 pages d'écran

Voilà, c’est exactement la raison pour laquelle j’aime bien quand ces discussions se déroulent sans moi.
J’ai failli supprimer mon message juste après l’avoir posté. C’est difficile à suivre, même pour celui qui l’a écrit.

Pour donner l’idée générale, et en espérant que je n’embrouille pas plus le propos : je pense qu’il faudrait diminuer drastiquement le nombre de boites de dialogue et d’icônes cliquables qui apparaissent dans KompoZer. La plupart des environnement de développement modernes (IDEs) ont recours à des panneaux (latéraux ou horizontaux) qu’on peut éventuellement passer en fenêtre flottante (très pratique quand on dispose de deux écrans), je pense que ça rend l’interface plus claire. De plus, avec la généralisation des écrans larges (16/9 et 16/10), on gagne à utiliser plus de panneaux latéraux et moins de barres d’outils.

Actuellement, il y a deux obstacles à cette révolution d’interface :

• le code n’est pas prêt pour ça : il faut d’abord repenser la façon dont certaines propriétés sont appliquées, puis faire en sorte qu’on n’ait plus besoin des boutons OK/Annuler pour valider les modifications ;
• la disposition des champs dans les boites de dialogue est telle qu’on ne peut pas se contenter de passer brutalement ces boites de dialogue en panneaux latéraux : il faudrait commencer par repenser ces boites de dialogues, pour qu’elles adoptent un format vertical, compatible avec un affichage en panneau latéral.

Voila pourquoi cette évolution est un boulot à relativement long terme.

Pour l’éditeur CSS :
Je voudrais vraiment l’avoir en panneau latéral plutôt qu’en boite de dialogue, mais je n’ai pas trouvé comment le faire rentrer dans un panneau latéral. J’ai donc commencé par faire la DOM sidebar, en me disant qu’à terme on pourrait éditer les propriétés CSS :

• soit directement dans le panneau latéral (comme avec FireBug), pour les utilisateurs avancés
• soit en double-cliquant sur une propriété pour faire apparaître la boite de dialogue qui va bien (= la boite des styles internes, grosso modo)

Cette évolution de l’éditeur CSS sera l’objet de la branche 0.8. Je crois que c’est le nœud du problème dans l’utilisation de KompoZer…

Pour les propriétés HTML :
C’est un peu plus compliqué : j’avais essayé jadis de faire ce que suggère jmj, à savoir afficher les attributs HTML de chaque élément directement dans l’arbre DOM, mais ça rendait l’affichage particulièrement obscur. Je n’ai pas encore trouvé d’idée d’interface qui me convienne, mais je voudrais garder le même principe : l’utilisateur avancé tripoterait directement l’arbre du panneau latéral (interface similaire à la boite des propriétés avancées), l’utilisateur humain se contenterait de cliquer pour faire apparaître une boite de dialogue.

Avis aux amateurs
Si vous avez le temps et la motivation pour poster des maquettes d’interface, ça serait intéressant pour la branche 0.9. Il n’est pas interdit de s’inspirer de l’existant (DreamWeaver, Expression Web, etc.) ! C’est un boulot ingrat, car fastidieux et sans résultat à court terme. C’est donc hautement facultatif, mais si vous pensez avoir une bonne idée, n’hésitez pas à la proposer : ça donnera le cap pour la branche 0.9.
À plus court terme, si vous avez des suggestions pour l’outil « pinceau » et la refonte de la page des propriétés de la page, lâchez-vous : ça pourrait être envisagé dans la branche 0.8.

Voilà, maintenant vous avez 4 pages écran de baratin abscons au lieu de deux.

Bonjour
Promis, je lirai avec beaucoup d'attention tout ce qui a pu sortir de vos délires les plus fous dès que je serai rentré. Là, pas trop de temps entre la piscine, le blog délire, les visites,etc...
Une question préliminaire quand même: KompoZer dans 10 ans aura-t-il encore du sens à exister? La question ne vise pas KpZ mais tous les logiciels d'aujourd'hui. N'y a-t-il pas une telle mutation en cours que, dans dix ans, on rigolera de tout ce que nous faisons maintenant?
Ou non?
Je fonce à la piscine. Salut.

Ymai a écrit : Une question préliminaire quand même: KompoZer dans 10 ans aura-t-il encore du sens à exister?

Comme éditeur HTML, sûrement ; comme éditeur ouèbe, rien n’est moins sûr…

Mon crédo c’est qu’un bon éditeur HTML peut s’avérer un redoutable outil de bureautique (traitement de texte et présentations, notamment). Le (x)HTML est le seul format de fichiers vraiment pérenne et interopérable : l’OpenDocument d’OOo n’est toujours pas lu correctement par l’écrasante majorité des utilisateurs bureautique.

Par contre, j’ai du mal à croire qu’on développera encore des sites ouèbe avec un éditeur wysiwyg dans 10 ans : les technologies mises en œuvre sont toujours plus complexes (PHP, Ajax, etc.), les CMS sont de plus en plus simples à mettre en œuvre, et les réseaux sociaux se substituent peu à peu aux sites ouèbe des particuliers.

Ceci dit, je pense qu’un éditeur CSS wysiwyg doublé d’un bon gestionnaire de sites aura toujours sa place dans 10 ans — mais je m’attends à ce que le nombre d’utilisateurs se restreigne fortement : de moins en moins d’amateurs auront recours à un éditeur HTML wysiwyg, et les pros auront de plus en plus besoin d’un IDE orienté programmation plutôt que d’un éditeur wysiwyg. Voilà pourquoi Komodo me paraît bien mieux placé que KompoZer pour l’avenir du développement ouèbe…

[HS] Je suis plus inquiet sur l’avenir des clients mail.
Un logiciel comme Thunderbird, qui ne fait *que* du mail (pas de travail collaboratif, pas de support pour les autres protocoles de communication, ni même une synchronisation des données personnelles), a objectivement peu à apporter aux utilisateurs pro (qui passent par Outlook ou des serveurs de travail collaboratif) et encore moins aux particuliers (qui utilisent un webmail).
Ça m’inquiète dans la mesure où ça ne rime plus à grand-chose d’utiliser du logiciel libre si nos données personnelles nous échappent, car gérées par des serveurs tels que Gmail dont le but est d’utiliser ces données à des fins commerciales. [/HS]

Kazé a écrit :je pense qu’il faudrait diminuer drastiquement le nombre de boites de dialogue et d’icônes cliquables qui apparaissent dans KompoZer. La plupart des environnement de développement modernes (IDEs) ont recours à des panneaux (latéraux ou horizontaux) qu’on peut éventuellement passer en fenêtre flottante (très pratique quand on dispose de deux écrans), je pense que ça rend l’interface plus claire.

Tu veux dire "à la mode scribus"?
Scribus peut ne présenter que la barre de menus en haut et tout le reste se passe en différentes boites ou barres (verticales ou horizontales): la boite "propriétés" est particulièrement complète et pourrait peut-être être une base de travail pour l'éditeur css.

chinon37 a écrit :Tu veux dire "à la mode scribus"?

J’avoue que je ne connaît pas vraiment Scribus… mais oui, le panneau des propriétés me plaît bien. C’est tout-à-fait dans l’esprit d’un panneau latéral KompoZer : les propriétés sont regroupées par sections, et si l’écran n’est pas assez grand on peut avoir recours à une barre de défilement vertical.

Par contre, je trouve un peu dommage dans Scribus que ces fenêtres ne soient pas « dockables », et qu’on doive jongler avec tant de fenêtres volantes… mais c’est souvent le cas pour les outils dédiés aux graphistes (GIMP, ’toshop, Illustrator…). Quand on dispose de deux écrans ça doit être pratique (on met toutes les fenêtres volantes sur le deuxième écran), dans le cas contraire je trouve ça un peu pénible. Idéalement, il faudrait donc que KompoZer 0.x dispose de panneaux détachables.

Dans une moindre mesure, il y a aussi l’exemple de Lotus Symphony, qui est la version propriétaire (gratuite) d’OpenOffice.org faite par IBM, et où les propriétés sont disponibles directement dans un panneau latéral.

Dans Gimp, les fenêtres volantes peuvent regroupées en une seule sous forme d'onglets :



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

Kazé a écrit : Par contre, je trouve un peu dommage dans Scribus que ces fenêtres ne soient pas « dockables », et qu’on doive jongler avec tant de fenêtres volantes… mais c’est souvent le cas pour les outils dédiés aux graphistes (GIMP, ’toshop, Illustrator…).

D'accord avec toi pour l'absence d'ancrage et de "dockage" sur scribus.
Par contre, Adobe fait ça très bien, du moins sur les dernières versions
Exemple pour 'tochope":
Déplié

replié

fenêtres balladeuses

et Illustrator le gère encore mieux.
A noter que Inkscape le gère, du moins dans les dernières nightlies de la 0.47

Faites pas attention à la photo, il cherche sans arrêt à imiter son maitre

jpbardiau a écrit :Dans Gimp, les fenêtres volantes peuvent regroupées en une seule sous forme d'onglets

chinon37 a écrit : Adobe fait ça très bien, du moins sur les dernières versions […]
A noter que Inkscape le gère, du moins dans les dernières nightlies de la 0.47

Au temps pour moi. J’avoue mon ignorance crasse envers ces outils-là.
Je retiens quand même que si même les infographistes s’y mettent, c’est bien que le concept de panneau latéral détachable est pertinent. Y’a plus qu’à.

Maintenant que je pense avoir compris la demande... si j'ai un peu de temps en septembre, je me pencherais là-dessus