Journal Edit Interactive SVG 1.2

Posté par  . Licence CC By‑SA.
16
22
mai
2021
Ce journal a été promu en dépêche : Edit Interactive SVG 1.2.

Intro

L'éditeur de SVG Interactif prenait la poussière et j'ai fini par prendre le temps nécessaire pour lui redonner un petit coup de jeune.

Pour ceux qui suivent un peu le projet, nous arrivons à la version 1.2 qui suit la 1.1 https://linuxfr.org/users/mothsart/journaux/edit-interactive-svg-1-1

Cette version m'a permis de répondre a des besoins exprimés depuis sa version 1.0 (https://linuxfr.org/users/mothsart/journaux/editeur-de-svg-interactif) donc 3 ans d'attente :

  • rajouter des contenus multimédia directement dans les commentaires :
    Il était déjà possible de rajouter des images (png, gif, jpg), il est désormais possible de compléter avec des vidéos, des sons ou de la musique.
    Néanmoins, j'encourage à utiliser cette fonctionnalité avec parcimonie car elle implique d'encapsuler l'ensemble dans un seul fichier et sous une forme textuel (base64) et par conséquent 1/3 plus voulumineux.

  • pouvoir gérer un historique de modification ce qui inclus l'ajout des boutons "annuler"/"restaurer" et la possibilité de naviguer sur l'ensemble des modifications effectués.
    Cette partie, pas foncièrement la plus demandé mais nécessaire à mon sens m'a donné le plus de fil à retordre pour adapter le code actuel et évité des régressions.
    Je mentirais en disant que tout a été testé dans ce domaine et marche parfaitement tellement les cas d'utilisation peuvent être sournois.

  • La possibilité de remplacé le fichier svg source sans perdre les méta-données liés au soft : indices, titres, commentaires, zoom etc.
    C'était confus auparavant : j'ai donc distingué "ajout" et "remplacement".

Sous le capot

  • stabilité et refactoring : Je l'avait exprimé dans la version 1.1 : il devenait difficile de retoucher au soft sans impacter sa stabilité.
    Des tests automatisés ont été rajoutés et le soft a été découpé en une arborescence de fichiers bien plus digeste à la relecture.
    Ce dernier oblige désormais un "make build" après toute édition mais c'est un mal pour un bien et une fois mis en place, le soft gagne en qualité et en lisibilité.

  • correctifs divers : Vu que ça fait un moment que je n'avais pas touché au soft, j'ai revue pas mal de petits détails sur l'aspect graphique mais aussi des petits bugs subtils.
    Je ne me suis pas concentré à les lister mais je peux juste dire qu'ils étaient nombreux.

Vous souhaitez l'utiliser

Les sources restent disponible ici : https://github.com/mothsART/editInteractiveSVG
Pour debian/ubuntu, le ppa a été maj : https://launchpad.net/~jerem-ferry/+archive/ubuntu/app-illustration

Pour les plus pressés d'entre vous, j'ai maj également la version on-line : https://mothsart.github.io/labo/frontend/edit_interactive_svg/

Que nous réserves une nouvelle version

Ce projet a été initié il y a 4 ans et fait ce qu'on lui demande sans forcément de nouvelles évolutions.
Je suis allé bien plus loin que ce que j’envisageais pour ce soft et en suit donc satisfait.
J'ai d'autres projets en tête (et en cours) et il me parait malhonnête d'annoncer de futures évolutions alors que je sais d'avance que je n'y accorderais que peu de temps.
Pour l'instant, je préfère dire que je vais maintenir le soft à son strict nécessaires : corrections de bugs inévitables.

Si vraiment je repartais sur le projet, voici les axes que je donnerais :

  • un nouveau nom, de nouvelles technos et une nouvelle identité graphique : un des objectifs étaient de me débarrasser de pas mal de libs tel que jquery, bootstrap etc.
    Force est de constaté que repartir de zéro sera bien plus bénéfique que tendre vers ce point itérativement.

  • une appli serveur avec toutes les améliorations que ça implique : stockage, compte utilisateur, ajax etc.

  • réfléchir PWA : pouvoir installer l'éditeur comme une appli mobile ou tablette.

  • plus de contenus : de nouveaux exemples (toute contribution est bienvenue)

  • rajouter des images (png, jpg) à l'ouverture (ou glissé-déposé) d'un nouveau fichier :
    un peu bizarre quand on parle d'éditeur interactif de "SVG" mais je pense que le commun des mortels ne fait pas foncièrement la différence :
    Si son fichier est matriciel mais avec une définition suffisante, l'intérêt d'ajouter une étape pour le convertir en SVG me parait faible.

  • l'amélioration de certaines parties techniques :

    • ajout d'une barre de progression sur l'importation de fichiers lourds
    • optimiser d'avantages le css/js (minification, concaténation)
    • quelques retouches visuels (checkbox non natives)
    • la possibilité d'utiliser des images au format Avif (voir webp)
    • la possibilité de minifier à la volée les fichiers importés et exportés
    • conserver l'historique des modifications dans le fichier de travail (en HTML) : lié au passage full serveur.
  • # Une dépêche!

    Posté par  (site Web personnel) . Évalué à 6.

    Il faut une dépêche pour ce journal.

    Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

    • [^] # Re: Une dépêche!

      Posté par  (site Web personnel) . Évalué à 6. Dernière modification le 30/05/21 à 15:39.

      C'est en cours fait. Il pourrait d'ailleurs être intéressant d'en faire un cas d'école sur pourquoi le passage par la rédaction collaborative est plus intéressant pour ce type de contenu.

      (édité après la publication de la dépêche)

      • [^] # Re: Une dépêche!

        Posté par  . Évalué à 2.

        Tiens, c'est dommage que ce lien (rédaction d'une dépêche en cours) ne face pas une redirection vers la dépêche quand elle est approuvé.

        • [^] # Re: Une dépêche!

          Posté par  (site Web personnel) . Évalué à 3. Dernière modification le 26/05/21 à 21:37.

          La question revient réglulièremnt : ce n'est pas le même texte, il peut y avoir d'autres contributeurs, ce n'est pas publié sous le nom (/users/xxxx) de l'auteur initial, ce ne sont pas les mêmes commentaires, ça obligerait à dépublier le journal, etc. Il y a des pour et des contre. Ici, vu qu'il n'y a pas vraiment de commentaires ici, une méthode aurait pu être de virer le journal dès le départ en fait (et l'idéal d'avoir fait une dépêche initialement, à mon avis).

          Quand je disais que c'était un cas d'école :

          • Ce journal a fait 670+546+322+223+184 hits en 5j. La dépêche a fait 185+3218+2174+837 hits actuellement. Côté visibilité y a pas photo, les dépêches sont plus reprises, plus lues, plus vues (en direct, via les flux Atom, par courriel, par fax, par pigeon voyageur, etc.).
          • La dépêche contient moins de fautes et plus d'infos (dont une description du logiciel qui manquait). Il suffit de comparer les deux markdown pour voir les changements des 26 éditions par 4 personnes.
          • La dépêche a déjà plus de commentaires sur le fond.
          • etc.
          • [^] # Re: Une dépêche!

            Posté par  . Évalué à 5.

            Il parlait du lien vers une dépêche en cours de rédaction, pas le journal initial.

            https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

            • [^] # Re: Une dépêche!

              Posté par  . Évalué à 2.

              Tout à fait.

              • [^] # Re: Une dépêche!

                Posté par  (site Web personnel) . Évalué à 4.

                Et le lien en question pointe sur la dépêche publiée quand elle est publiée.

                • [^] # Re: Une dépêche!

                  Posté par  . Évalué à 3.

                  https://linuxfr.org/redaction/news/edit-interactive-svg-1-2

                  Ce lien tombe en 404

                  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                  • [^] # Re: Une dépêche!

                    Posté par  (site Web personnel) . Évalué à 4.

                    « Ce journal a été promu en dépêche : Edit Interactive SVG 1.2.. » qui pointe vers https://linuxfr.org/news/edit-interactive-svg-1-2 qui est le lien de la dépêche publiée. Qui du coup n'est plus en rédaction, et donc ce journal n'a plus de lien vers la dépêche en rédaction vu qu'elle n'y est plus. Je ne vois toujours pas le problème.

                    • [^] # Re: Une dépêche!

                      Posté par  . Évalué à 3.

                      Ce que dit mothsART c'est que ça pourrait être sympa que :

                      https://linuxfr.org/redaction/news/edit-interactive-svg-1-2

                      redirige vers

                      https://linuxfr.org/news/edit-interactive-svg-1-2

                      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                      • [^] # Re: Une dépêche!

                        Posté par  (site Web personnel) . Évalué à 4.

                        Pourquoi vouloir rediriger un lien qui n'est plus censé exister, qui n'a pas la même fonction, et dont la redirection empêcherait de distinguer une dépêche en rédaction d'une dépêche publiée ? Sans parler du fait que les droits ne sont pas les mêmes sur les dépêches publiées (éditables par la modération) que sur la rédaction (éditable par les visiteurs). C'est un lien prévu pour être transitoire et qui disparaît avec la modération, que la dépêche soit publiée ou rejetée (et qui peut réapparaître sur un renvoi en rédaction).

                        Une dépêche en rédaction c'est :
                        /redaction/news/titre1 qui peut devenir /redaction/news/titre2 , /redaction/news/titre3 (avec des redirections entre elles vers le choix courant).

                        Par exemple :
                        /redaction/news/ffv1-un-format-video-sans-perte-et-libre-standardise-a-l-ietf
                        qui est devenu
                        /redaction/news/ffv1-un-format-video-sans-perte-et-libre-normalise-a-l-ietf

                        qui deviendra /moderation/news/<slug> lors de sa modération (rendant le /redaction/news/<slug> invalide)
                        qui deviendra /news/<slug> lors de sa publication (et le /moderation/news/<slug> sera toujours valide, pour la modération).

                        • [^] # Re: Une dépêche!

                          Posté par  . Évalué à 3.

                          Pourquoi vouloir rediriger un lien qui n'est plus censé exister, qui n'a pas la même fonction, et dont la redirection empêcherait de distinguer une dépêche en rédaction d'une dépêche publiée ?

                          Tu peux très bien distinguer puisque tu n'arrive pas sur la même URL finale.

                          Encoder l'état d'un contenu dans son URL est une façon de faire, mais c'est loin d'être la seule et prendre le parti d'avoir une URL qui pointe sur le contenu où qu'il soit dans le processus (et t'envoie une erreur s'il n'existe pas ou si tu n'y a plus accès) à d'autres avantages. Tu as bien moins de liens morts, tu n'a plus a jongler entre les URL (pour ceux qui suivent l'ensemble du processus, ils n'ont pas à géré les toutes les url), tu peux faire des liens d'une dépêche à une autre qui propose de participer à la rédaction puis qui pointera sur la version publiée.

                          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                        • [^] # Re: Une dépêche!

                          Posté par  . Évalué à 3.

                          Une dépêche, c'est pourtant pas Le chat de Schrödinger, il peut pas être à la fois en modération, publié ou rejeté, non ?

                          Une autre possibilité serait de ne pas supprimer mais de mettre un petit contenu :
                          "Cette dépêche en rédaction a été a été publié ici : url."

                          ou

                          "Cette dépêche a été rejeté par l'équipe de modération"

                          J'essai de réfléchir "visiteur". Le gars qui passe dans un an, qui connait pas tous les rouages de linuxfr, il voit que le lien ramène vers une 404, il en déduit que la dépèche n'existe pas/plus.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.