Ne pas forcer les icones en 32x32 #25

Open
opened 1 year ago by cam.lafit · 9 comments
cam.lafit commented 1 year ago
Collaborator

Le code de gis_icon_properties impose que l'image finale sera forcée à une largeurxhauteur de 32.

https://git.spip.net/spip-contrib-extensions/gis/src/branch/master/gis_fonctions.php#L483

Dans certains cela n'est pas souhaitable. Peut on envisager d'avoir une option à la méthode permettant de définir la taille finale de recadrage ?
Pour la rétrocompatibilité on pourrait avoir 32 par défaut.

Le code de gis_icon_properties impose que l'image finale sera forcée à une largeurxhauteur de 32. https://git.spip.net/spip-contrib-extensions/gis/src/branch/master/gis_fonctions.php#L483 Dans certains cela n'est pas souhaitable. Peut on envisager d'avoir une option à la méthode permettant de définir la taille finale de recadrage ? Pour la rétrocompatibilité on pourrait avoir 32 par défaut.
b_b commented 1 year ago
Collaborator

Ça pourrait oui, il faudrait aussi définir une option pour le test ici https://git.spip.net/spip-contrib-extensions/gis/src/branch/master/gis_fonctions.php#L482 ?

Ça pourrait oui, il faudrait aussi définir une option pour le test ici https://git.spip.net/spip-contrib-extensions/gis/src/branch/master/gis_fonctions.php#L482 ?
b_b added the
amélioration
label 1 year ago
Owner

clairement ça empêche d'avoir des png en x2 par exemple (à défaut de svg), et il faudrait revoir ça.

Eventuellement avec un argument de taille comme celui de balise_img en spip 4 ?

clairement ça empêche d'avoir des png en x2 par exemple (à défaut de svg), et il faudrait revoir ça. Eventuellement avec un argument de taille comme celui de balise_img en spip 4 ?
b_b commented 1 year ago
Collaborator

Pour ce qui est des images en x2, Leaflet gère ça nativement pour les images par défaut des points, cf https://git.spip.net/spip-contrib-extensions/gis/src/branch/master/lib/leaflet/dist/leaflet-src.js#L7172 ; il faudrait donc définir la propriété iconRetinaUrl dans les options du json généré pour les icônes.

Dans tous les cas, merci de lancer le chantier dans une branche dédiée, histoire de ne pas rejouer le running gag qu'on a eu sur centerAndZoom() :)

Pour ce qui est des images en x2, Leaflet gère ça nativement pour les images par défaut des points, cf https://git.spip.net/spip-contrib-extensions/gis/src/branch/master/lib/leaflet/dist/leaflet-src.js#L7172 ; il faudrait donc définir la propriété `iconRetinaUrl` dans les options du json généré pour les icônes. Dans tous les cas, merci de lancer le chantier dans une branche dédiée, histoire de ne pas rejouer le running gag qu'on a eu sur `centerAndZoom()` :)
Poster
Collaborator

Hello

Pour le test en dur de 44px je n'ai pas compris le cas d'usage. De plus 44 != 64 si on fait une multiplication. Donc sur ce point je laisse à l'expertise des bonnes personnes.

Mon patch prend en compte juste une variable $taille et remplace les valeurs en dur 44 et 32 dans la fonction.

Hello Pour le test en dur de **44px** je n'ai pas compris le cas d'usage. De plus 44 != 64 si on fait une multiplication. Donc sur ce point je laisse à l'expertise des bonnes personnes. Mon patch prend en compte juste une variable *$taille* et remplace les valeurs en dur 44 et 32 dans la fonction.
Owner

git blame pointe d3354d3699

Mais du coup je pense qu'il faut être plus clair dans le fonctionnement

  • si pas d'argument de taille fourni, garder le comportement historique qui réduit en 32px si plus grand que 44px
  • si argument de taille fourni, le respecter
  • quitte à étendre la fonction, prévoir d'emblée un tableau d'option en second argument plutot que juste une taille ?

Je pense qu'il serait bien de pouvoir préciser en option

  • une image shadow associée à l'image si besoin
  • de préciser l'alignement à base de center, left, right, top, bottom, du genre "top left" ou "center" ou "bottom" (aka "bottom center") car actuellement c'est inféré en fonction de si l'image est carrée ou non et c'est pas idéal dans tous les cas, je me rappele avoir du réécrire un filtre quasi identique juste pour gérer l'alignement
  • et donc de préciser une taille de picto
git blame pointe https://git.spip.net/spip-contrib-extensions/gis/commit/d3354d369925b469352dfd4aa0ec97df734f3677 Mais du coup je pense qu'il faut être plus clair dans le fonctionnement - si pas d'argument de taille fourni, garder le comportement historique qui réduit en 32px si plus grand que 44px - si argument de taille fourni, le respecter - quitte à étendre la fonction, prévoir d'emblée un tableau d'option en second argument plutot que juste une taille ? Je pense qu'il serait bien de pouvoir préciser en option - une image shadow associée à l'image si besoin - de préciser l'alignement à base de center, left, right, top, bottom, du genre "top left" ou "center" ou "bottom" (aka "bottom center") car actuellement c'est inféré en fonction de si l'image est carrée ou non et c'est pas idéal dans tous les cas, je me rappele avoir du réécrire un filtre quasi identique juste pour gérer l'alignement - et donc de préciser une taille de picto
b_b commented 1 year ago
Collaborator

Tout ça me semble très bien, et quitte à reprendre cette fonction, y ajouter une option pour la génération automatique d'une image en x2.

Tout ça me semble très bien, et quitte à reprendre cette fonction, y ajouter une option pour la génération automatique d'une image en x2.
Collaborator

Coucou,

j'ai pas fais tous ce que Cerdic prevoit, mais la modif de taille est ici, elle fonctionne et suffit dans de nombreux cas :

https://git.spip.net/Yohooo/gis.git

Coucou, j'ai pas fais tous ce que Cerdic prevoit, mais la modif de taille est ici, elle fonctionne et suffit dans de nombreux cas : https://git.spip.net/Yohooo/gis.git

hello @Yohooo, merci, cependant sur la forme, on a volontairement tous les droits sur l'orga des plugins, justement pour pouvoir tous créer des branches communes, modifiables par tous.

Il ne faut donc pas forker dans un truc perso, la règle est de créer une branche de dev dans le plugin même avec un nom clair pour savoir de quoi il s'agit, par exemple "git branch dev/issue_25_taille_icone". De cette façon, tout le monde peut facilement basculer pour tester sans cloner un autre dépôt + on peut tous apporter des corrections en cascade.

hello @Yohooo, merci, cependant sur la forme, on a volontairement *tous* les droits sur l'orga des plugins, justement pour pouvoir tous créer des branches communes, modifiables par tous. Il ne faut donc pas forker dans un truc perso, la règle est de créer une branche de dev dans le plugin même avec un nom clair pour savoir de quoi il s'agit, par exemple "git branch dev/issue_25_taille_icone". De cette façon, tout le monde peut facilement basculer pour tester sans cloner un autre dépôt + on peut tous apporter des corrections en cascade.
Collaborator

OK, @rastapopoulos,

En plus, je me rend compte que @cam.lafit l'avait déjà proposé ici :
https://git.spip.net/spip-contrib-extensions/gis/src/branch/issue_25

J'ai apporté qq corrections. Mais pour moi c'est OK

OK, @rastapopoulos, En plus, je me rend compte que @cam.lafit l'avait déjà proposé ici : https://git.spip.net/spip-contrib-extensions/gis/src/branch/issue_25 J'ai apporté qq corrections. Mais pour moi c'est OK
Sign in to join this conversation.
No Milestone
No Assignees
5 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.