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 GG (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 Benoît Sibaud (site web personnel) . Évalué à 6. Dernière modification le 30 mai 2021 à 15:39.
C'est
en coursfait. 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 mothsART . É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 Benoît Sibaud (site web personnel) . Évalué à 3. Dernière modification le 26 mai 2021 à 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 :
[^] # Re: Une dépêche!
Posté par barmic 🦦 . É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 mothsART . Évalué à 2.
Tout à fait.
[^] # Re: Une dépêche!
Posté par Benoît Sibaud (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 barmic 🦦 . É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 Benoît Sibaud (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 barmic 🦦 . É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 Benoît Sibaud (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/titre1qui 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-ietfqui 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 barmic 🦦 . Évalué à 3.
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 mothsART . É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.