Améliorations souhaitées sur KompoZer (bientôt Noël)

[Kazé]

Bonjour,

je suis actuellement en négociation avec un éventuel sponsor pour KompoZer. Ce sponsor a pour objectif immédiat de corriger le bug du placement de la poignée sur les "calques" :

Code : Tout sélectionner

<div
 style="border-style: solid; border-width: 1px; margin-top: 100px; margin-left: auto; margin-right: auto; width: 400px; position: relative; height: 60px;">
<div style="position: absolute; top: 10px; left: 100px;">Boite1</div>
<div style="position: absolute; left: 300px; top: 30px;">Boite2</div>
</div>

• coller le code ci-dessus dans un document HTML
• cliquer sur 'boite1' ou 'boite2' > la poignée de déplacement du calque est décalée.

Notez que la résolution de ce bug va grandement faciliter la création de zones réactives en CSS.

J'ai dû faire un devis trop modeste, puisque cette société m'a demandé de proposer d'autres améliorations à KompoZer. Autrement dit, il y aurait peut-être un sponsor pour financer la version de Noël.
Comme cette société a beaucoup de bonne volonté mais assez peu de moyens, je crois qu'il faut se limiter à ce qui manque le plus aux débutants Nvu/KompoZer. J'ai pensé à plusieurs choses simples :

• un gestionnaire de sites évolué, avec double vue locale/remote, et intégration de FireFTP (certains ici se souviennent peut-être de la dernière beta de NsmConText...) histoire de résoudre les problèmes de publication pour les débutants ;
• une boite de dialogue spécifique pour les <div>, plus intuitive (cf. propriétés des "cadres" d'OOo) et plus adaptée aux débutants ;
• un 'assistant de création de site' qui permettrait de créer une mise en page personnalisable et d'y appliquer par la suite des thèmes fournis par de généreux contributeurs ;
• un 'dock' source en bas de fenêtre, pour visualiser / éditer rapidement le code HTML de la balise courante (sans coloration syntaxique), comme sur cette version-ci ;
• [EDIT] adapter WebDevelopper à KompoZer ; [/EDIT]
• ou d'autres corrections de bugs pénibles...

Pour que ça rentre dans leur (petit) budget, je pense leur proposer toutes les améliorations que j'ai bricolées mais pas finies, dont certaines que je pensais garder pour une version 'pro'. Il y en a sûrement que j'ai oubliées.

Je ne doute pas que vous ayez, vous aussi, une idée précise de ce qui vous manque dans KompoZer, c'est pourquoi je viens solliciter votre avis.

L'urgence, c'est que je dois envoyer un devis demain soir. Je leur proposerai plusieurs options, en espérant qu'ils en achèteront le plus possible, mais il me semble évident qu'ils ne financeront pas tout...

[EDIT] Le devis est parti, vous pouvez toujours proposer des améliorations ici mais je garantis encore moins que ça va être utile... [/EDIT]

À vos claviers !

[Ymai]

Perso, j'en reviens très fort des "calques" en position absolue, mais bon...

Une autre petite bêtise, mais qui m'énerve un tantinet:
http://info.sio2.be/NVU/3/3.php
Dans le premier bloc bleu.

[edit]S'il est permis de faire des souhaits pour le gestionnaire de sites (hors roadmap, me semblait-il): lui donner de la mémoire.
Dans un grand site, ce serait bien de pouvoir se retrouver dans le dernier répertoire sur lequel on a travaillé, lorsqu'on redémarre KpZ.
Quoi de plus énervant que d'aller rechercher dans le sixième sous-répertoire (j'exagère à peine) le dernier fichier que l'on a touché.
Surtout après un plantage.

A propos de plantage: n'y a-t-il aucun moyen de surveiller la cause de ceux-ci? A part le fait qu'ils surviennent le plus fréquemment quand on a un grand nombre de fichiers modifiés et non enregistrés (loi de la vexation universelle), quelles peuvent en être les causes?
La console Javascript ne dit rien, et pour cause. [/provisoire edit]

[edit 2]Rendre le correcteur orthographique fonctionnel, lui qui fait planter KpZ plus vite que Kazé ne code. Ne fût-ce que pour éviter les coquilles, quand on tape trop vite.[/edit2]

[Kazé]

J'ai oublié une proposition : adapter WebDevelopper à KompoZer.
Parmi les propositions que j'ai évoquées plus haut, y en a-t'il qui vous semblent plus particulièrement importantes ?

Perso, j'en reviens très fort des "calques" en position absolue, mais bon...

Entièrement d'accord, mais en l'occurrence le client en a besoin pour une bonne raison...

Une autre petite bêtise, mais qui m'énerve un tantinet:
http://info.sio2.be/NVU/3/3.php
Dans le premier bloc bleu.

Je l'avais oublié celui-là...
En gros, avec un bouton 'div' dans la barre d'outils, on pourrait plus facilement imbriquer des <div>.

[Kazé]

S'il est permis de faire des souhaits pour le gestionnaire de sites (hors roadmap, me semblait-il): lui donner de la mémoire.
Dans un grand site, ce serait bien de pouvoir se retrouver dans le dernier répertoire sur lequel on a travaillé, lorsqu'on redémarre KpZ.
Quoi de plus énervant que d'aller rechercher dans le sixième sous-répertoire (j'exagère à peine) le dernier fichier que l'on a touché.
Surtout après un plantage.

Noté. C'est faisable assez facilement je pense.

A propos de plantage: n'y a-t-il aucun moyen de surveiller la cause de ceux-ci? A part le fait qu'ils surviennent le plus fréquemment quand on a un grand nombre de fichiers modifiés et non enregistrés (loi de la vexation universelle), quelles peuvent en être les causes?

Ce n'est pas simple du tout à implémenter ; ça excèderait de beaucoup le budget du sponsor potentiel. Firefox est pourvu d'un système de ce genre, mais il est propriétaire (pour l'instant).

[Ymai]

Et le fameux bug du déplacement d'un bloc au-dessus de la zone d'édition.
Prendre un bloc par sa poignée et tenter de le déplacer vers le haut de l'écran.
Après un minimum de passages, KpZ crashe au moment de ré-ancrer le bloc.

[Do-IT]

- vrai éditeur 'externe' indenté dans l'onglet source
- assistant de création de formulaire
- propriétés image map
- meilleur support utf8
- meilleur support php
- correcteur orthographique

[Ymai]

- meilleur support utf8

- &pi;
- &euro;
Bref, on reprend tous les bugs connus et l'on prie tous ensemble?

[Kazé]

Oui, c'est le moment de lister les bugs les plus gênants !
Attention : je ne m'attends vraiment pas à ce que l'éventuel sponsor assume le développement de tous les bugs restants, il fera son propre tri.

1. Concernant le bug du déplacement d'un bloc au-dessus de la zone d'édition, j'ai commencé à regarder ça, mais pour l'instant je patauge. Si je trouve ça sera un coup de bol. D'ici là, ne pas lâcher son calque au-dessus de la zone d'édition !
2. Pour les questions d'encodage, c'est du coté de HandCoder qu'il faut chercher l'erreur. Sans HandCoder ni Tidy, on n'a jamais d'erreur d'encodage. La seule solution sera d'intégrer Tidy dans HandCoder, mais ça nécessite encore pas mal de boulot et de test, sans parler du fait que Daniel commence à développer ça pour MC2.
3. Quant à l'éditeur 'externe' indenté dans l'onglet source, vu la tournure que prend le travail de Paul Rouget sur son plug-in Scintilla, ça prend bonne tournure ; mais là aussi, il y a encore beaucoup de boulot.
4. Le support PHP dépend directement des points 2 et 3. D'où le fait que je rechigne à intégrer HandCoder dans KompoZer pour l'instant.
5. Pour les propriétés image map, ça me parait intéressant mais pas fondamental. AMHA, un bête bouton "créer une vignette" dans la boite des propriétés d'image serait plus utile dans l'immédiat.
   Je crois qu'il faudrait songer à une extension plus complète pour la manipulation d'images : redimensionnement, rotation, création de vignettes... et pourquoi pas image map. On pourrait recourir à un logiciel en ligne de commande comme ImageMagick pour faire le boulot de conversion, avec une interface rudimentaire pour triturer l'image (à la souris) et créer un image map (au clavier ?).
6. Pour l'assistant de création de formulaire, il faudrait une idée plus précise : quels types de formulaire ? On se limiterait à un formulaire mail ? Ou faudrait-il implémenter un livre d'or, etc ? Il faudrait alors des scripts dont la licence serait compatible avec KompoZer, ou un mécanisme de 'greffons' PHP. Y a-t'il un équivalent chez DW ?
   Quoiqu'il en soit, il y a effectivement pas mal de débug à faire sur les formulaires.
   [HS] Au passage, les champs cachés de formulaire sont désormais visibles et cliquables. [/HS]
7. Pour le correcteur orthographique, je vais voir s'il est possible d'arranger le bousin. Ce dernier point me parait très important, il faudra que je regarde le code pour voir si je peux le corriger.

Dans la foulée du point #5, il faudrait faire aussi une fenêtre de propriétés "objet" (ou "media"), pour insérer facilement un composant audio, vidéo ou flash.

[Do-IT]

2. J'avais bien compris qu'il vaut mieux rester en iso pour l'instant, et plutôt chercher des solutions du type mbstring.
3. 4. > Kzpack+ ?
5. Imagemagik > -1 (il y a assez d'outils externe pour ca)
6. Formulaire pour envoyer un mail uniquement, (puis créer un fichier csv éventuellement).
Formulaire HTML (fait avec l'assistant) = 1 fichier html -> script mail en php (généré par l'assistant) = un fichier php -> Confirmation HTML (fait par kz) = un fichier html
La relative difficulté est de faire un script php générique et sécurisé compatible avec une majorité d'hébergeurs. Je peux faire une beta.
livre d'or > -1
7. c'est avec hc que ça coinçait

fenêtre de propriétés "objet" (ou "media") > +1

[Sebaz]

KompoZer est un outil de travail que j'utilise quasi quotidiennement. Aussi, je viens plusieurs fois par semaine pour lire les nouveaux messages ici dans la section de forum Nvu : l'éditeur de pages Web au format HTML. Je n'ai malheureusement aucune requête/suggestion à faire et ne puis qu'admirer votre niveau de connaissance technique. La seule chose que je puis faire est de vous remercier et vous encourager à continuer Mille et un merci!

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7

[Ymai]

KompoZer est un outil de travail que j'utilise quasi quotidiennement.

La seule chose que je puis faire est de vous remercier et vous encourager à continuer Mille et un merci!

+1

[chinon37]

pour les 2 messages ci-dessus: +1

[JujuLand]

Une petite requête que j'ai exprimée dans un autre post, mais qui n'a eu apparemment aucun echo:

Pouvoir, par un switch en ligne de commande ou autrement (paramêtre de Kompozer) ouvrir plusieurs fichiers dans une instance de Kompozer déjà ouverte.

A+


Message envoyé avec : Mozilla/5.0 (Windows; U; Win98; fr; rv:1.8.0.7pre) Gecko/20060829 K-Meleon/1.02

[Do-IT]

Un menu qui se reproduit sur toutes les pages ?
J'avais oublié l'include php. Alternative 1

Ou à défaut un include html ?
Modele (voir code source). Menu.
Pourquoi pas un menu dans un fichier html complet. Suffirai d'inclure ce qu'il y a dans le body.
Public visé: débutant avec un petit site.
Le luxe serait que les mises à jour du menu se répercute automatiquement. (ou à la demande).

[Kazé]

Le devis est parti, je vous tiendrai au jus des suites...

Une petite requête que j'ai exprimée dans un autre post, mais qui n'a eu apparemment aucun echo:

Pouvoir, par un switch en ligne de commande ou autrement (paramêtre de Kompozer) ouvrir plusieurs fichiers dans une instance de Kompozer déjà ouverte.

C'est un bug. Pour l'instant je ne l'ai pas regardé, je le corrigerai si je peux, mais je me vois mal aller démarcher des sponsors pour ça.
Le corollaire, sous Linux, c'est que si KompoZer est déjà lancé et qu'on clique à nouveau sur son icone, on a droit au sélecteur de profil... beurk.

Un menu qui se reproduit sur toutes les pages ? [...]
Public visé: débutant avec un petit site.
Le luxe serait que les mises à jour du menu se répercute automatiquement. (ou à la demande).

Il y a une méthode pour faire ça sans PHP, qui est accessible aux débutants, compatible avec tous les éditeurs HTML, qui se met à jour automatiquement, et qui ne nécessiterait aucune extension : ça s'appelle <iframe> (pas taper !).
La seule chose qu'il faudrait faire, c'est empêcher que l'utilisateur ne puisse sélectionner un élément à l'intérieur des <iframe> (ça crée un bug pénible). Éventuellement, ajouter une boite de propriétés quand on double-clique sur un <iframe>, et basta. Ça devrait être possible.

Pour les utilisateurs plus avancés, il faudra faire une série de pseudo-instructions pour insérer des fragments et des champs spéciaux (date notamment), en s'inspirant de ce que fait DW, autant que possible. Le genre de choses qui collerait très bien à HandCoder.