Hop,
On en était à newsletter_logo.svg.
Vous pensez que c’est vraiment un problème ?
J'aimerais comprendre le "et paf".
Le logo du plugin a priori sera utilisé uniquement dans SVP/SPIP sur la page de liste des plugins, et charger avec `_DIR_PLUGIN_XX . {le nom choisi}.svg`. Pas de surcharge ici possible. (J'ai pas vérifié)
Une personne qui mettrait un squelettes/home.svg le chargeant avec #CHEMIN{...} ou que sais-je, ce fichier serait prioritaire dans le path. Donc ça n'utiliserait pas non plus celui du plugin.
Alors donc je présume que c'est possiblement bon comme ça.
Par contre… si une page veut réutiliser différents logo de plugins en s'appuyant uniquement sur le prefixe, et ferait #CHEMIN{$prefixe.svg} alors là il y aurait probablement problème.
Mais je suis aussi d'accord pour ne pas utiliser directement {prefixe}.svg qui me parait un peu trop simple, a première vue...
MM.
Le logo du plugin a priori sera utilisé uniquement dans SVP/SPIP sur la page de liste des plugins, et charger avec `_DIR_PLUGIN_XX . {le nom choisi}.svg`. Pas de surcharge ici possible. (J'ai pas vérifié)
Ah ok, je pensais principalement à ce cas là, mais si les images sont chargées comme ça, ça ne devrait pas poser problème à cet endroit en effet.
Par contre… si une page veut réutiliser différents logo de plugins en s'appuyant uniquement sur le prefixe, et ferait #CHEMIN{$prefixe.svg} alors là il y aurait probablement problème.
Et donc oui, c'est ce genre de cas auxquels on ne pense pas forcément dès le début, mais on tombe souvent sur ces exceptions après coup.
Mais je suis aussi d'accord pour ne pas utiliser directement {prefixe}.svg qui me parait un peu trop simple, a première vue...
Moi c'est pour ça que plugin_<prefixe>.svg me semblait rester simple et assez logique.
Re,
Je rajoute une bille sur la simplification 
Là on parle d'une recommandation pour SPIP 4. Grosse version, gros changements.
Ça ne me parait pas *du tout* déconnant, et en plus c'est vraiment un "incompatibilité" super minime, de dire aux gens : bah oui à partir de maintenant arrêtez de laisser votre bordel à la racine et rangez votre chambre, merde.
On va pas s'empêcher d'avoir des noms simples et bien rangés, parce que 3 pauvres gens laissent leurs chaussettes sales.
Donc pour moi, même prefixe.svg suffit en théorie.
Aux gens qui font des squelettes en bordel de mettre leurs images dans… /images. Suffit de l'écrire clairement dans la release.
Donc ok, on part sur prefixe.svg à la racine.
Je rajoute aussi une petite digression sur les thèmes.
Le logo représente le plugin; il n’a pas forcément à être réutilisé dans les icones des thèmes.
Deux exemples pour illustrer:
Le plugin Territoires à un préfixe territoires et donc un logo à la racine de nom territoires.svg. Un territoire est aussi un objet spip: il y a donc un icone territoire-xx.svg dans les thèmes pour représenter cet objet qui est différent du graphisme du logo.
Le plugin Simples Logs à un préfixe simplog et donc un logo simplog.svg à la racine (nouvelle branche spip 4). Initialement tout était dans les thèmes et donc il existait des icones simplog-16.png, etc. dans les thèmes. En fait, j’ai viré ces icones en les remplaçant par un svg log-xx.svg car l’objet est un log pas un simplog. Dans le cas présent néanmoins, le graphisme est le même.
Hop,
Le 10/05/2021 à 11:42, Eric Lupinacci via Discuter de SPIP a écrit :
Donc ok, on part sur prefixe.svg à la racine.
Super, il faudra penser à ajouter l’info sur
Rédaction du paquet.xml - Plugins SPIP ?
++
b_b
Ok super, ça va simplifier, c’est bon les choses bien nommées et bien rangées 
J’ai une petite interrogation en corollaire.
Certains plugins comme Simplog justement insère une entrée dans un menu du privé.
Par exemple:
<menu nom="simplog_bt" titre="simplog:logs" parent="menu_administration" icone="images/log-16.png" action="simplog" />
L’icone doit-il représenter le logo du plugin ?
Si oui, le fait de ne pas avoir -xx à la fin du nom peut-il poser un souci ?
Si on appelle icone="simplog.svg" dans la balise menu est ce que ça fonctionne ?
Sinon, on fait quoi?
@erational a proposé un compromis très intéressant je trouve :
/{prefixe}-xx.svg
Du coup
- on est quasi sûr que ça interfère pas, et
- on rappelle le nommage dans les thèmes
Je me reposais la question à l’instant et je remarque qu’on ne l’a toujours pas ajouté à https://plugins.spip.net/redaction-du-paquet-xml.html :d
/{prefixe}-xx.svg me semble d’autant plus pertinent que ça permet de récupérer tels quels les logos SVG des plugins existants qui sont, en général, de la forme .../prive/themes/spip/images/{prefixe}-xx.svg
Exact on a toujours pas adopté réellement cette logique ni on l’a décrite quelque part.
Par contre, on avait plus ou moins entériné que le logo serait à la racine avec un nom qui coïncide avec le préfixe du plugin, soit prefixe.svg.
Ca parait assez logique car le logo n’est pas destiné à être réutilisé autrement qu’en logo.
En cela je répond à @cy_altern car si un plugin décrit un objet patate et même si le préfixe est patate, je pense qu’il faut créer un icone patate-xx.svg dans les thèmes d’images qui soit clairement séparé : qu’il reprenne le look & feel du logo n’est pas une raison pour le réutiliser à partir de la racine.
L’idée initiale est bien de séparer les thèmes d’icones et le logo.
Oui mais à partir du moment où un plugin est compatible SPIP 3 et SPIP 4, il faut fournir son logo dans les 2 formats patate-64.png et patate-xx.svg (même si on est à la racine). Car si on mets seulement un patate.svg le logo sera cassé en SPIP 3
Oui exact, c’est encore le cas pour ceux qui traversent spip 3 et 4.
Ca milite peut-être pour appliquer systématiquement cette règle que pour les plugins uniquement spip 4.
Par contre, la séparation logo et thèmes peut elle être appliquée indépendamment du nommage du logo.
Et en spip 5 on essayera de se débarrasser des cas spip 3 
Perso je parlais uniquement des plugins compatibles SPIP 4, SPIP3.2 est en fin de support, et je suis d’accord avec @eric_tonton un plugin maintenu et compatible SPIP 4 devrait avoir une branche dédiée.
Moui enfin j’ai un peu de mal avec les ayatollahs des branches. C’est parfois très pertinent de brancher, parfois pas du tout.
Par exemple sur le plugin bank qui est et sera encore utilisé sur des versions SPIP 3.x pendant un bout de temps, ce serait bien plus couteux et risqué pour moi de maintenir 2 branches pour 2 versions de SPIP, avec du coup le besoin de tester tout en double. Il est beaucoup plus safe d’avoir une seule version qui tourne partout et d’y fixer les bugs et évolutions d’API que de gérer des divergences entre branches…
Donc ce « devrait » me parait être un peu trop directif si je puis me permettre et ne pas vraiment prendre en compte les diverses réalités du terrain et de chaque plugin…
Bref donc je pense que c’est bien qu’on ait une convention idéale pour les plugins 4+ c’est parfait, et une solution propre pour les plugins 3.2+ même si elle est moins idéale.
1 « J'aime »
Les branches c’est bien, mangez-en, na 
Tout à fait 