KompoZer 0.8 : amélioration de la vue « Mixte »

Kazé · Message par **Kazé** » 11 mars 2010, 00:43

Bonjour,

j’essaye de déverminer la vue Mixte, dans l’espoir de livrer quelque chose d’utilisable pour la 0.8 finale. J’aurais besoin de votre aide pour lister les problèmes rencontrés lors de l’utilisation de cette vue Mixte.

Voilà une copie de ma version de travail : kompozer-rev219.tar.gz (archive GNU/Linux)

[EDIT] la dernière version en date (rév.223) est la suivante :

kompozer-rev223.zip archive Windows
kompozer-rev223.dmg image MacOSX
kompozer-rev223.tar.gz archive GNU/Linux

L’idée de cette révision 220 est de tester le « verrouillage » du mode Mixte. Merci de donner votre avis sur la question dans ce fil de discussion, et de rapporter les éventuels bugs que vous rencontrez.[/EDIT]

Après avoir longuement cogité la question, je crois qu’il faut bosser sur les deux aspects suivants pour stabiliser cette vue Mixte.

<1> Fermeture automatique de la vue Mixte
La vue Mixte pose un tas de soucis dus au fait que le dock Source ne contient pas nécessairement le code de l’élément courant. Pour y remédier, il faudrait que je mette à jour le dock Source au fur et à mesure de la frappe ; ça fonctionne assez bien sur mes propres pages, mais sur les pages de mon fiston (= interminables Pokédex sans le moindre paragraphe) ça revient à recalculer le code de <body> à chaque pression de touche, ce qui pose des problèmes de performance évidents.

Sur cette version de travail (rev 219), la vue Mixte se ferme automatiquement :

quand on passe en vue Mixte (clic sur l’onglet Mixte, Alt+Enter), le curseur est placé dans cette vue — enfin, il devrait : pour l’instant ce n’est pas le cas, je me garde un peu de souplesse pour faire des tests
dès que le curseur sort de cette vue (clic dans la fenêtre principale, Alt+Enter / Espace), on repasse en vue Conception

Cela revient à avoir une simili boite de dialogue : aucun problème de performances, aucun conflit d’édition.
Ça permet encore d’inspecter le code du document en jouant avec l’explorateur DOM, et ça correspond parfaitement à l’usage que j’en ai (Alt+Entrée, modification rapide, Alt+Entrée) — mais qu’en est-il pour vous, est-ce que vous voyez des inconvénients majeurs à cette fermeture automatique ?

<2> Mieux appliquer les modifications apportées en vue Mixte
Modifier un élément en passant par la vue Mixte revient à sélectionner l’élément avec la barre d’état et utiliser « Insert > HTML… ». KompoZer utilise alors la méthode « insertHTML » de l’éditeur Mozilla pour remplacer la sélection par le code HTML passé en argument.

Or, je m’aperçois que cela ne fonctionne pas toujours correctement, loin s’en faut. J’ai notamment vu deux cas problématiques :

impossible de modifier les attributs d’une cellule de tableau <td>, probablement parce que KompoZer ne peut supprimer que le contenu d’une cellule et non la cellule elle-même
impossible de remplacer un élément de liste <li> par deux éléments de liste sans couper la liste en deux. Pareil pour les listes de définition (dt/dd)

Il y a très certainement d’autres cas problématiques, merci de me les rapporter dans ce fil de discussion. J’envisage deux façons de résoudre ces problèmes :

<2a> limiter la vue Mixte à l’édition de blocs
Quand l’utilisateur veut éditer un élément <li>, <td> ou autre dans le même cas, KompoZer lui proposerait automatiquement le bloc conteneur (i.e. respectivement <ul/ol>, <table>, etc.).
<2b> éditer le contenu de l’élément plutôt que l’élément lui-même
cela reviendrait à utiliser la propriété innerHTML, bien connue des adeptes de JavaScript. Ça aurait des conséquences assez lourdes sur l’interface.

Je préfèrerais nettement l’option 2a, mais elle n’est envisageable que si tous les autres cas où la vue Mixte refuse d’appliquer les modifications sont similaires à <li> et <td>. Voilà pourquoi j’ai besoin de vos rapports de bugs.

État actuel (rév.219)
La fermeture automatique est partiellement implémentée. Ça devrait être suffisant pour se faire une idée, mais c’est encore loin d’être « béton » : on peut arriver assez facilement à garder le dock source ouvert sans qu’il ait le focus. Je peaufinerai ça par la suite, si personne ici ne trouve de problème rédhibitoire à cette option.
Pour l’application des modifications en vue Mixte, je suis parti sur l’option <2a> :

je pense avoir trouvé un gros hack crado pour résoudre le problème des listes (<ol>, <ul>, <dl>), à confirmer.
n’ayant pas pu corriger le problème pour les cellules de tableau, la vue Mixte refuse désormais d’éditer une cellule de tableau, et propose d’éditer tout le tableau. C’est très pénible à cause de l’absence d’indentation, je vais bosser sur la question.

Il faudrait donc vérifier que les listes sont désormais éditables sans trop de souci, et mentionner les autres cas d’édition qui ne fonctionneraient pas.
Par ailleurs, on m’a rapporté que la vue Mixte pouvait générer des freezes (i.e. KompoZer ne plante pas mais il prend 100% de CPU et ne répond plus, il faut faire un killall). C’est pire qu’un crash, si quelqu’un pouvait trouver une procédure pour reproduire ce bug, ça serait un grand progrès. Un boulot pour Do-IT quoi. ^^

Désolé pour la grosse tartine, j’essaye d’être concis mais le problème est assez complexe et il me faut être précis pour que vos tests puissent être profitables au projet. Je publierais des binaires Linux dans ce fil de discussion au fur et à mesure de vos rapports de test.

Merci !

Kazé · Message par **Kazé** » 11 mars 2010, 03:45

Ahem, je viens de faire quelques tests, et je regrette déjà d’avoir mis cette version de travail en ligne. Outre les bugs d’interface, je viens de voir que :

la vue Mixte montre du code non formaté, ce qui est particulièrement pénible quand on édite un tableau ou une liste (et ce, avec toutes les versions de KompoZer 0.8 publiées jusqu’ici)
la vue Source montre du code joliment formaté par le sérialiseur Gecko 1.8.1 (incomparable avec Nvu / KpZ 0.7)
en acceptant le fait que la vue Mixte se ferme automatiquement, je peux faire en sorte que le code affiché dans l’éditeur soit reformaté comme dans la vue Source : il suffirait pour cela qu’en passant en vue Mixte, l’élément à éditer soit sélectionné dans la vue principale (ça paraît idiot mais techniquement c’est comme ça que Gecko fonctionne)

Je n’avais pas pensé à cette option car j’étais bêtement habitué au sérialiseur Gecko 1.7 de Nvu / KpZ 0.7, qui est vraiment horrible. Mais le sérialiseur Gecko 1.8.1 est bien meilleur, et si j’arrive à intégrer le patch de Laurent Jouanneau, il sera même au niveau de HTML Tidy.

Ça fonctionnerait pour tous les éléments à l’exception de <html> et <head> (qui peuvent toujours être édités dans la vue Source). Ça représente un peu de boulot mais au vu de mes premiers résultats, je crois que le jeu en vaut vraiment la chandelle. Je me laisse un peu de temps pour y réfléchir, mais si personne ici ne voit de problème au fait de fermer automatiquement la vue Mixte, je m’y colle dès que possible.

Désolé pour le monologue, je crois que je n’ai plus qu’à supprimer ce topic.

Do-IT · Message par **Do-IT** » 11 mars 2010, 11:57

rev219.
En mode mixte :
- Les modifications du code ne sont pas conservées. En mode source c'est ok.
- Un clic sur la fenêtre du haut ne mets pas à jour le contenu et ne bascule pas en mode conception. Il faut 2x Alt+Enter pour basculer en mode conception (les modifications du code sont perdues).

<1> Ma méthode de travail préférée serait de bricoler le code en mode mixte et de voir en temps +/- réel le résultat en visuel au dessus, agrémentée de clics sur la fenêtre du haut soit pour éditer le contenu en wysiwyg soit pour obtenir un autre bout de code source dans l'onglet du bas. Donc je suis contre le basculement vers le mode conception.

<2a> J'ajoute et je modifie sans arrêt les balises du code. Si tu vires les balises ça perd en souplesse.

Pour l'instant ca freeze pas, ça plafonne à 3%. La nuit y'a des fortes probabilités de monologue, pendant que d'autres picolent, dorment ou changent des couches pleines (au choix).

Kazé · Message par **Kazé** » 11 mars 2010, 14:12

Je me suis complètement raté sur la rev.219, je vais faire en sorte de proposer quelque chose de plus utilisable rapidement.
Un petit avant/après pour expliciter le boulot en cours sur la vue Mixte — ici avec un tableau de deux lignes et trois colonnes :

C’est grâce au fait que le tableau est sélectionné que je peux reformater le code du dock source. C’est couillon mais c’est comme ça.

Do-IT a écrit :<1> Ma méthode de travail préférée serait de bricoler le code en mode mixte et de voir en temps +/- réel le résultat en visuel au dessus, agrémentée de clics sur la fenêtre du haut soit pour éditer le contenu en wysiwyg soit pour obtenir un autre bout de code source dans l'onglet du bas. Donc je suis contre le basculement vers le mode conception.

Hum, certes.

Prenons l’exemple du tableau ci-dessus : si on est en vue Mixte et qu’on modifie le contenu du tableau, ou qu’on ajoute/supprime des cellules, je ne peux pas mettre à jour le contenu du dock source en temps réel (problème de performances sur des gros tableaux). Ça laisse deux options :

<1a> faire en sorte que les modifications wysiwyg ne soient faisables qu’en mode Conception : c’est une limitation assez forte mais c’est le moyen le plus simple de garder une application véloce, et de garantir la stabilité de la vue Mixte à court terme ;
<1b> rafraîchir le contenu du dock source quand on clique dedans : c’est plus souple, mais perturbant à l’utilisation. Quand on veut sélectionner une partie du code dans le dock pour le modifier, dès qu’on relâche le bouton de souris la sélection est perdue à cause du rafraîchissement.

Pour ceux qui voudraient bosser essentiellement depuis le dock source, il faut que je regarde si je peux ajouter une option pour « verrouiller » le mode Mixte. L’option <1a> suppose de fermer le dock source dès qu’on clique dans la zone d’édition wysiwyg ; si le dock source est verrouillé, un clic dans la zone wysiwyg sélectionnerait un nouvel élément et présenterait son code dans le dock source (idem quand on sélectionne un nouvel élément avec l’explorateur DOM ou la barre d’état). Il faudrait alors cliquer sur l’onglet « Conception » pour revenir à un mode purement wysiwyg.

Ou alors, je pourrais essayer d’implémenter les deux options <1a> et <1b> : l’option <1b> reviendrait plus ou moins à un mode Mixte verrouillé.

Dans les deux cas, il faudra que je rajoute une pref cachée — genre editor.source.AutoCloseSplitView, qui serait vraie par défaut, et que les utilisateurs avancés pourraient désactiver.

Do-IT a écrit :<2a> J'ajoute et je modifie sans arrêt les balises du code. Si tu vires les balises ça perd en souplesse.

Oui, c’est *la* raison pour laquelle je préfèrerais cette méthode-là. Par ailleurs, c’est nettement plus pratique pour ajouter ou modifier un attribut HTML.
Pour ça, il faudrait faire le tour des modifications qui ne sont pas réellement appliquées. Vu le ratage sur la rev.219, autant partir de la 0.8b3 pour lister les cas pénibles en attendant que j’arrive avec une meilleure solution.

Do-IT · Message par **Do-IT** » 11 mars 2010, 15:01

La performance c'est subjectif, est-ce une raison valable pour ne pas innover ? (début du 1er troll)

Si on décompose les actions du mode mixte :
- Edition du code => pas de mise à jour en temps réel du wysiwyg => il faut le signaler (dock wysiwig qui se grise => F5 pour rafraichir [sans quitter le dock du source]) / ou clic fenêtre du haut pour passer en wysiwyg (on suppose qu'on a fini l'édition du code)
- Edition wysiwig > pas de mise à jour en temps réel du dock source => idem que ci-dessus (dock source qui se grise => F5 pour rafraichir [idem sans perdre le position du curseur] / ou clic ou autre raccourci de ton cru impossible à mémoriser pour passer dans le dock source (début du 2ème troll)

Ca rejoint ta proposition <1b> même si j'ai pas pigé ton problème de sélection (pourquoi veux tu rafraichir le dock source lorsque tu édites le dock source).
On oublie la redirection vers conception et la pref cachée.

Jamais 2 trolls sans 3 : ça existe encore les tableaux ?

Oui je sais, F5 dans Nvu/kz ca fait un truc bizarre au lieu de rafraichir. (mince encore un troll, ...)

Kazé · Message par **Kazé** » 11 mars 2010, 17:29

Do-IT a écrit :La performance c'est subjectif, est-ce une raison valable pour ne pas innover ? (début du 1er troll) […]
Jamais 2 trolls sans 3 : ça existe encore les tableaux ?

Pour les données tabulaires, les tableaux saybien.

L’exemple ci-dessus concerne un tableau parce que c’est là que la différence de formatage est la plus évidente, mais le vrai problème de performances concerne plutôt <body>, notamment pour des longues pages sans structure : à chaque nouveau caractère il faut rafraîchir tout le code de <body>, ce qui prend du temps — facilement une seconde sur une petite machine avec une longue page sans paragraphe. À moins d’accepter qu’on tape à moins de 60 caractères par minute, ça veut dire que le CPU est à 100%, donc freeze de Kompozer.
Ce critère de performance n’est donc pas si subjectif que ça.

Do-IT a écrit :- Edition du code => pas de mise à jour en temps réel du wysiwyg => il faut le signaler (dock wysiwig qui se grise => F5 pour rafraichir [sans quitter le dock du source]) / ou clic fenêtre du haut pour passer en wysiwyg (on suppose qu'on a fini l'édition du code)
- Edition wysiwig > pas de mise à jour en temps réel du dock source => idem que ci-dessus (dock source qui se grise => F5 pour rafraichir [idem sans perdre le position du curseur] / ou clic

Griser le dock wysiwyg ou garder la position du curseur dans le dock source, c’est loin d’être simple (si tant est que ça soit possible actuellement). Sur ma version du moment, j’essaye quelque chose qui me paraît plus intuitif :

Édition du code = mode Mixte
le dock wysiwyg est désactivé : quand on clique dedans, ça sélectionne un nouvel élément à afficher dans le dock source. On valide les modifications du dock source avec Alt+Entrée ou un clic dans le dock wysiwyg. Le curseur est donc toujours dans le dock source.
Édition wysiwyg = mode Conception
si on veut modifier des éléments en wysiwyg, il faut sortir du mode Mixte.

Ça revient donc à verrouiller le mode Mixte par défaut. Je trouve ça assez sympa, ça marche aussi bien au clavier qu’à la souris, je tâche de peaufiner l’idée pour vous la faire tester ce week-end.

Do-IT a écrit :…ou autre raccourci de ton cru impossible à mémoriser pour passer dans le dock source (début du 2ème troll) […]
Oui je sais, F5 dans Nvu/kz ca fait un truc bizarre au lieu de rafraichir. (mince encore un troll, ...)

Si tu as de meilleurs raccourcis clavier à proposer (pour changer de mode d’édition, pour lancer le navigateur, etc.), je suis preneur. Attention : pour faciliter le travail des équipes de traduction, on est en string freeze jusqu’à la sortie de la 0.8 (voire pour toute la branche 0.8), et on ne peut donc pas ajouter des raccourcis de type Ctrl+lettre ou Alt+lettre.

Kazé · Message par **Kazé** » 13 mars 2010, 05:52

Voilà une version corrigée (révision 220) :

kompozer-rev220.zip archive Windows
kompozer-rev220.dmg image MacOSX
kompozer-rev220.tar.gz archive GNU/Linux

C’est une reprise assez importante du code (plus de 1100 lignes de patch). Je ne l’ai pas beaucoup testée mais elle devrait nettement mieux fonctionner — en tout cas, le code sera nettement plus facile à faire évoluer qu’avec la révision précédente.

Dans cette version, je suis parti sur l’option « mode Mixte verrouillé » : impossible de faire des modifications dans la zone d’édition wysiwyg, le curseur est bloqué dans le dock source. Je vous laisse essayer et me dire ce que vous en pensez.

La bascule clavier Conception / Mixte (Alt+Entrée ou Échapp.) fonctionne différemment :

quand on est en mode Conception, Alt+Entrée permet de passer en mode Mixte temporairement : on revient au mode Conception avec Échapp (annulation) ou Alt+Entrée (validation). Ça revient à utiliser une boite de dialogue : c’est très rapide si on utilise les raccourcis clavier, c’est économe en ressources CPU, ça me convient bien.
si on est passé en mode Mixte en cliquant sur l’onglet éponyme (ou en utilisant le menu "Afficher"), on est en mode verrouillé : Alt+Entrée rafraîchit l’élément courant dans la vue wysiwyg, Échapp réinitialise le dock source — le tout, sans fermer le dock. La vue Mixte est alors bien adaptée à ceux qui travaillent essentiellement en source.

Dans les deux cas : si on est mode Mixte, un clic dans la zone wysiwyg sélectionne automatiquement un élément et repasse le curseur dans le dock source. L’option « fermeture automatique » consisterait à fermer le dock source dès qu’on clique dans la zone wysiwyg, ce qui serait peut-être plus intuitif pour les débutants (ou pas ?).

[EDIT] ça n’a rien à voir et tout le monde s’en fout (avec raison), mais si j’en crois les dates de publication des révisions 219 et 220 j’ai pondu 1117 lignes de patch en 53 heures. Appelez-moi le Guiness book ! \o/ [/EDIT]

Message par **Ymai** » 13 mars 2010, 09:13

Kazé a écrit :Dans cette version, je suis parti sur l’option « mode Mixte verrouillé » : impossible de faire des modifications dans la zone d’édition wysiwyg, le curseur est bloqué dans le dock source. Je vous laisse essayer et me dire ce que vous en pensez.

Impeccable. Cette bascule entre Mode Mixte et Mode Conception me paraît extrêmement intuitive. Le grand confort.

Kazé a écrit : Dans les deux cas : si on est mode Mixte, un clic dans la zone wysiwyg sélectionne automatiquement un élément et repasse le curseur dans le dock source. L’option « fermeture automatique » consisterait à fermer le dock source dès qu’on clique dans la zone wysiwyg, ce qui serait peut-être plus intuitif pour les débutants (ou pas ?).

A mon sens, celui qui s'en va errer dans le mode mixte doit un peu savoir ce qu'il fait. Sinon, il ne serait pas là.
La possibilité de cliquer n'importe où dans le volet "Conception" et de retrouver le code source correspondant me paraît être un incontournable maintenant. Après 3 minutes, je ne peux plus m'en passer.
Quant à ceux qui constateront que KpZ est bloqué après être passé en mode mixte, ils finiront bien par comprendre qu'en cliquant sur l'onglet "Conception", ils retrouveront leurs jeunes.
La situation actuelle me convient bien, mais il faudra peut-être attendre les retours de ceux qui entrent par accident en mode mixte.

Ai-je déjà suffisamment exprimé tout le plaisir que j'ai à utiliser KpZ 0.8 ?

Kazé a écrit : [EDIT] ça n’a rien à voir et tout le monde s’en fout (avec raison), mais si j’en crois les dates de publication des révisions 219 et 220 j’ai pondu 1117 lignes de patch en 53 heures. Appelez-moi le Guiness book ! \o/ [/EDIT]

On pourrait toujours aller boire une Guiness ?
Tiens, il n'y a pas un peu de vent dehors? Qu'en disent les toiles?

Message par **Ymai** » 13 mars 2010, 09:18

Tout petit souci, me semble-t-il:
Alt+Enter ouvre le mode mixte, Alt+Enter le ferme

Clic sur l'onglet "Split" ouvre le mode mixte. Alt+Enter ne le ferme pas

Il faut donc se souvenir de la façon dont on est entré en mode mixte. Pas trop intuitif...

Message par **Ymai** » 13 mars 2010, 13:58

Juste un détail: il faudrait penser à désactiver
* markup cleaner
* validate html
dans le menu tools lorsque l'on passe en mode mixte.
Ou alors, les laisser vraiment actifs

Kazé · Message par **Kazé** » 13 mars 2010, 15:53

Ymai a écrit :Tout petit souci, me semble-t-il:
Alt+Enter ouvre le mode mixte, Alt+Enter le ferme
Clic sur l'onglet "Split" ouvre le mode mixte. Alt+Enter ne le ferme pas
Il faut donc se souvenir de la façon dont on est entré en mode mixte. Pas trop intuitif...

Le pire, c’est que c’est fait exprès.

Je me suis souvenu que tu avais suggéré qu’on puisse ouvrir / fermer la vue Mixte avec Alt+Entrée, j’ai donc appliqué l’idée et je trouve ça *très* pratique à l’usage. D’où l’idée initiale de fermer automatiquement le mode mixte.
Mais suite aux remarques de Do-IT, je me suis aussi évertué à verrouiller la vue Mixte. J’ai donc ajouté une verrue dans le code pour que Alt+Entrée ou Échapp ne sorte pas du mode Mixte, mais appliquent ou annulent les modifications respectivement. Et j’avoue que je trouve ça pratique aussi.

L’ensemble est loin d’être intuitif, je le reconnais bien volontiers. Je vois au moins deux solutions possibles :

choisir définitivement entre le mode « fermeture automatique » et le mode « verrouillé ». Je pourrais ajouter facilement une préférence cachée que les plus dégourdis iraient basculer avec about:config, s’ils ne sont pas satisfaits du mode par défaut.
ajouter un indicateur dans le dock source pour montrer si on est en mode « fermeture automatique » ou « verrouillé ». Par exemple, en affichant un cadenas dans le coin inférieur droit du dock source, pour indiquer qu’on est en mode verrouillé.

Parallèlement, il serait probablement bon que je rajoute des raccourcis plus clairs pour passer d’un mode d’édition à l’autre. Je pensais utiliser F2/F3/F4 pour Design/Split/Source : ces raccourcis seraient affichés en clair dans le menu « Affichage », chose qu’il m’est plus difficile de faire avec Alt+Entrée qui est une bascule (et non un accès direct à un mode d’édition).

Ymai a écrit :Juste un détail: il faudrait penser à désactiver
* markup cleaner
* validate html
dans le menu tools lorsque l'on passe en mode mixte.
Ou alors, les laisser vraiment actifs

Je vais voir si je peux les laisser actifs. Je sais que le Markup Cleaner peut fonctionner en vue mixte, et c’est sympa de voir l’effet en temps réel.

Ymai a écrit :
Kazé a écrit :[EDIT] ça n’a rien à voir et tout le monde s’en fout (avec raison), mais si j’en crois les dates de publication des révisions 219 et 220 j’ai pondu 1117 lignes de patch en 53 heures. Appelez-moi le Guiness book ! \o/ [/EDIT]
On pourrait toujours aller boire une Guiness ?
Tiens, il n'y a pas un peu de vent dehors? Qu'en disent les toiles?

Je suis plutôt Erdinger ou Chimay que Guiness, mais sur le principe je suis globalement toujours partant.

Pas assez de vent aujourd’hui pour sortir les cerf-volants, mais suffisamment de neige pour emmener ma progéniture au ski. La vie est belle.

Message par **Ymai** » 13 mars 2010, 16:18

Kazé a écrit :Mais suite aux remarques de Do-IT, je me suis aussi évertué à verrouiller la vue Mixte. J’ai donc ajouté une verrue dans le code pour que Alt+Entrée ou Échapp ne sorte pas du mode Mixte, mais appliquent ou annulent les modifications respectivement. Et j’avoue que je trouve ça pratique aussi.

Avec tout le respect et la déférence que je dois à Do-IT, je persiste à préférer la cohérence. Mais ce n'est que mon avis.
J'adore ce Alt+Enter que j'utilise tout le temps. J'avoue avoir perdu de vue le Esc pour annuler: je sens qu'il va aussi bien servir.

Chez moi, il y a un effet curieux quand on tient la touche Esc enfoncée 3 secondes. Le code HTML de la partie mixte s'évanouit. Mais, en fait, il est juste caché: rien n'est perdu. Il suffit de frapper Esc une fois de plus.

[edit]Bonne glisse[/edit]
Ouuupss... J'ai failli frapper Alt+Enter

Kazé · Message par **Kazé** » 13 mars 2010, 17:02

Je pense que le mode « fermeture automatique » (= [Esc] et [Alt+Entrée] ramènent au mode Conception) est parfait pour ceux qui privilégient le travail au clavier. Inversement, le mode « Mixte verrouillé » est très pratique à la souris, puisqu’on peut sélectionner un élément à éditer d’un simple clic dans la zone wysiwyg.

Ymai a écrit :Avec tout le respect et la déférence que je dois à Do-IT, je persiste à préférer la cohérence.

Moi aussi, mais ce n’est pas simple de garder un Alt+Entrée cohérent avec le concept de vue Mixte verrouillée. D’où les deux choix que je propose plus haut.

Le plus cohérent serait que lorsqu'on édite le source (vue Mixte ou Source), [Esc] et [Alt+Entrée] nous ramènent toujours à la vue Conception. Encore que : actuellement, si on est en vue Mixte, puis qu’on passe en vue Source, [Esc] / [Alt+Entrée] nous ramènent au dernier mode non-Source, en l’occurrence le mode Mixte.

Par ailleurs, quand on est en vue Mixte verrouillée, il nous faut un moyen de valider les modifications (= rafraîchissement de la zone wysiwyg) et un moyen de les annuler (= rafraîchissement du dock source). Do-IT avait suggéré d’utiliser F5 pour ça, mais est-ce que F5 doit rafraîchir la zone wysiwyg ou le dock source ? Pour éviter l’ambiguïté, j’ai préféré conserver [Alt+Entrée] et [Esc].
Ceci dit, une autre façon de considérer le problème consisterait à dire que si on est en vue Mixte, on peut toujours valider les modifications en cliquant dans la zone wysiwyg, ou les annuler en faisant un Ctrl+Z après être revenu en mode Conception.

Ymai a écrit :J'adore ce Alt+Enter que j'utilise tout le temps. J'avoue avoir perdu de vue le Esc pour annuler: je sens qu'il va aussi bien servir.

Je suis complètement accro à ces deux raccourcis, ainsi qu’aux Alt+flèches pour sélectionner des éléments. Je n’ai jamais eu une telle productivité avec aucun éditeur HTML : même Vim, que j’apprécie plus que de raison, ne peut rivaliser.
Mais si efficaces soient-ils, est-ce que ces raccourcis sont accessibles à l’utilisateur type de Kompozer ? Est-ce qu’on ne devrait pas plutôt proposer F2/F3/F4 par défaut pour changer de mode, et proposer ces raccourcis Alt+Entrée / Alt+flèches dans une extension (ce qui permettrait de les documenter) ?

Je nage un peu dans le brouillard pour l’instant. En attendant de lire d’autres retours, je vais bosser sur autre chose (probablement la préservation de la sélection en mode Source). De toute façon, je suis à Paris la semaine prochaine (Solutions Linux), donc je ne retoucherai pas cette vue Mixte avant une bonne semaine. Maintenant que j’y pense, il faudrait peut-être que je propose des versions Mac et Windows de cette version et que je les fasse tourner sur le forum anglo-saxon avant de partir à Paris…

Kazé · Message par **Kazé** » 13 mars 2010, 17:06

Ymai a écrit :Chez moi, il y a un effet curieux quand on tient la touche Esc enfoncée 3 secondes. Le code HTML de la partie mixte s'évanouit. Mais, en fait, il est juste caché: rien n'est perdu. Il suffit de frapper Esc une fois de plus.

Oui, j’ai repéré des cas où j’arrive à afficher un dock source vide. Je crois que c’est une conséquence du reformatage du code dans le dock source, il faut que je trouve une parade à ça.

Ce qui m’inquiète le plus, ce sont les cas où les modifications dans le dock source ne sont pas appliquées correctement au document HTML. Je me souviens que tu avais listé deux ou trois cas qui posaient problème, mais je ne remets plus la main sur ce post. De toute façon, le code a tellement changé depuis la 0.8b3 qu’il faudrait tester à nouveau pour faire un état des lieux.

Il ne faudrait pas perdre de vue que l’objectif initial de cette modification du mode Mixte était d’améliorer sa fiabilité.

Message par **Ymai** » 13 mars 2010, 18:22

Aïe... petit mélangeage de pinceaux entre l'onglet Split et l'onglet Design

Deux pages actives dans deux onglets de pages différents. Ces deux pages sont en mode Design.
Sur l'une des deux pages, je passe en mode Split.

Je passe à l'autre page. Elle est aussi en mode Split (est-ce ce qui est attendu?), mais l'onglet actif, au bas de la fenêtre, est Design.
Je clique sur Split: rien ne se passe (normal, on était déjà en split). Je clique sur Design: je repasse en mode Design (OK).

En passant d'une page à l'autre, il semble que le mode dans lequel se trouve la page ne soit pas bien "retenu". Une fois ça va, une fois, ça ne va pas.

J'ai eu pire, à deux reprises, tout à l'heure quand le contenu d'une page s'est retrouvé dans l'autre page (sauf la CSS qui est restée correctement affectée). Juste en jouant avec les modes (split/design) et les onglets. Mais je ne parviens pas à reproduire.

Geckozone

KompoZer 0.8 : amélioration de la vue « Mixte »

KompoZer 0.8 : amélioration de la vue « Mixte »

Re: KompoZer 0.8 : amélioration de la vue « Mixte »

Re: KompoZer 0.8 : amélioration de la vue « Mixte »

Re: KompoZer 0.8 : amélioration de la vue « Mixte »

Re: KompoZer 0.8 : amélioration de la vue « Mixte »

Re: KompoZer 0.8 : amélioration de la vue « Mixte »

Re: KompoZer 0.8 : amélioration de la vue « Mixte »

Re: KompoZer 0.8 : amélioration de la vue « Mixte »

Re: KompoZer 0.8 : amélioration de la vue « Mixte »

Re: KompoZer 0.8 : amélioration de la vue « Mixte »

Re: KompoZer 0.8 : amélioration de la vue « Mixte »

Re: KompoZer 0.8 : amélioration de la vue « Mixte »

Re: KompoZer 0.8 : amélioration de la vue « Mixte »

Re: KompoZer 0.8 : amélioration de la vue « Mixte »

Re: KompoZer 0.8 : amélioration de la vue « Mixte »

Qui est en ligne ?