salut tout le monde,
dans ce plugin materialicons j’ai cherché une manière d’utiliser facilement les icônes suivantes dans la rédaction ou les squelettes :
Dans le trunk, la v1 utilise le dépôt des images sur la zone pour les télécharger seulement à la demande, et stocke le contenu du svg dans la base, pour être par la suite autonome. Il y a un nouvel objet « materialicon », quand on en crée un on choisi le style - Rounded, Outlined, TwoTone - puis la catégorie - il y en a 16 - puis le nom de l’icône. En validant ça rempli le champ svg avec le code de l’image svg. Ensuite on peut styler la taille et les couleurs en css, voir déjà css/materialicons.css Le coup des images sur la zone qu’on télécharge à la demande, est-ce que ça vous semble perenne ? Ça évite de télécharger les 5Mo d’icônes à chaque fois… materialicons/ images/ (la librairie d’images) trunk/ (la v1, que le code du plugin, qui utilise à la demande les images du dépôt materialicons/images) C’est encore tout en dev, toute aide est bienvenue, ++ chan
Hop,
Le 27/06/2019 à 10:02, chankalan@choc0.net a écrit :
salut tout le monde,
dans ce plugin materialicons j'ai cherché une manière d'utiliser facilement les icônes suivantes dans la rédaction ou les squelettes :
https://icons.pixsellz.io/
Dans le trunk, la v1 utilise le dépôt des images sur la zone pour les télécharger seulement à la demande, et stocke le contenu du svg dans la base, pour être par la suite autonome. Il y a un nouvel objet "materialicon", quand on en crée un on choisi le style - Rounded, Outlined, TwoTone - puis la catégorie - il y en a 16 - puis le nom de l'icône. En validant ça rempli le champ svg avec le code de l'image svg.
Ensuite on peut styler la taille et les couleurs en css, voir déjà css/materialicons.css
Le coup des images sur la zone qu'on télécharge à la demande, est-ce que ça vous semble perenne ?
Ça évite de télécharger les 5Mo d'icônes à chaque fois...
J'ai toujours une réticence quand je vois débouler des paquets de Mo comme ça sur la zone, ça plombe l'historique et fait grossir la base du repo, mais bon...
Ça pose aussi problème dans les mails de commits, j'ai du valider à la main tes commits sur ce projet car la longueur du mail généré dépassait la limite autorisée par la liste.
Pour en revenir à la question du transfert, je trouve ça moyen sur le principe, mais Camille nous en dira ce qu'il en pense.
Si le site source n'avait pas utilisé un système avec demande d'email pour accéder au zip, tu aurais pu le déclarer comme une lib dans ton plugin et le déballer dans le dossier dédié à ça de chaque SPIP qui utilisera le plugin, dommage.
Amha c'est plus pérenne de récupérer tout le plugin à l'installation plutôt que de faire des hits à la demande.
PS : il faudrait vérifier que les auteurs du pack sont d'accord qu'on rende disponible celui-ci sur la zone, car on contourne leur système de téléchargement (même si c'est distribué sous licence apache).
++
b_b
Le 27/06/2019 à 10:20, Bruno Bergot a écrit :
Hop,
Le 27/06/2019 à 10:02, chankalan@choc0.net a écrit :
salut tout le monde,
dans ce plugin materialicons j'ai cherché une manière d'utiliser facilement les icônes suivantes dans la rédaction ou les squelettes :
https://icons.pixsellz.io/
Dans le trunk, la v1 utilise le dépôt des images sur la zone pour les télécharger seulement à la demande, et stocke le contenu du svg dans la base, pour être par la suite autonome. Il y a un nouvel objet "materialicon", quand on en crée un on choisi le style - Rounded, Outlined, TwoTone - puis la catégorie - il y en a 16 - puis le nom de l'icône. En validant ça rempli le champ svg avec le code de l'image svg.
Ensuite on peut styler la taille et les couleurs en css, voir déjà css/materialicons.css
Le coup des images sur la zone qu'on télécharge à la demande, est-ce que ça vous semble perenne ?
Ça évite de télécharger les 5Mo d'icônes à chaque fois...J'ai toujours une réticence quand je vois débouler des paquets de Mo comme ça sur la zone, ça plombe l'historique et fait grossir la base du repo, mais bon...
Ça pose aussi problème dans les mails de commits, j'ai du valider à la main tes commits sur ce projet car la longueur du mail généré dépassait la limite autorisée par la liste.
j'ai tenté pour voir... merci en tout cas...
Pour en revenir à la question du transfert, je trouve ça moyen sur le principe, mais Camille nous en dira ce qu'il en pense.
Si le site source n'avait pas utilisé un système avec demande d'email pour accéder au zip, tu aurais pu le déclarer comme une lib dans ton plugin et le déballer dans le dossier dédié à ça de chaque SPIP qui utilisera le plugin, dommage.
j'avais imaginé ça aussi... je me suis aussi demandé de faire un dépôt ailleurs sur un site perso, ça reste faisable
Amha c'est plus pérenne de récupérer tout le plugin à l'installation plutôt que de faire des hits à la demande.
PS : il faudrait vérifier que les auteurs du pack sont d'accord qu'on rende disponible celui-ci sur la zone, car on contourne leur système de téléchargement (même si c'est distribué sous licence apache).
oui c'est juste, je vais voir ça
++
b_b
--
----
chan
Salut
Dans l'absolu le transfert en soit ne pose pas un gros problème. En
proportion peu de personne sollicite directement la zone , c'est
plutôt file.spip.net qui est impacté car c'est lui qui va fournir le
gros zip et qui sera sollicité à chaque installation et par effet de
bord affecté la zone via smart_paquet.
Autrement de ce que j'en comprends on est dans le cas où <necessite
lib> est notre ami. Il me semble qu'on est bien dans ce cas d'usage.
Comme on essaye dans le mesure du possible de ne pas dupliquer les
fonctionnalités (un seul plugin par besoin, ....) au sein de la
communauté cela me semble du même registre lorsqu'on a besoin d'un
code tiers.
Dans certains cas cette solution n'est pas possible (téléchargement
par validation pas mail, captcha, licence, ....) dans ce cas on n'a
pas le choix. A mon sens (avis personnel) autant demander à la source
quand on peut avant et importer dans le svn en dernier recours.
Km
Le 27/06/2019 à 11:26, cam.lafit@azerttyu.net a écrit :
Salut
Dans l'absolu le transfert en soit ne pose pas un gros problème. En
proportion peu de personne sollicite directement la zone , c'est
plutôt file.spip.net qui est impacté car c'est lui qui va fournir le
gros zip et qui sera sollicité à chaque installation et par effet de
bord affecté la zone via smart_paquet.Autrement de ce que j'en comprends on est dans le cas où <necessite
lib> est notre ami. Il me semble qu'on est bien dans ce cas d'usage.
Comme on essaye dans le mesure du possible de ne pas dupliquer les
fonctionnalités (un seul plugin par besoin, ....) au sein de la
communauté cela me semble du même registre lorsqu'on a besoin d'un
code tiers.
ah oui, il faudrait que chaque utilisateur s'occupe de télécharger la librairie et de la mettre sur son serveur, ça résout le problème de la zone et du dépôt de la librairie, on contourne plus le formulaire de téléchargement, j'avais pas pensé à ça... on perd en facilité d'usage, mais c'est certainement préférable.
Dans certains cas cette solution n'est pas possible (téléchargement
par validation pas mail, captcha, licence, ....) dans ce cas on n'a
pas le choix. A mon sens (avis personnel) autant demander à la source
quand on peut avant et importer dans le svn en dernier recours.Km
--
----
chan
Le 27/06/2019 à 12:37, chankalan@choc0.net a écrit :
Le 27/06/2019 à 11:26, cam.lafit@azerttyu.net a écrit :
Salut
Dans l'absolu le transfert en soit ne pose pas un gros problème. En
proportion peu de personne sollicite directement la zone , c'est
plutôt file.spip.net qui est impacté car c'est lui qui va fournir le
gros zip et qui sera sollicité à chaque installation et par effet de
bord affecté la zone via smart_paquet.Autrement de ce que j'en comprends on est dans le cas où <necessite
lib> est notre ami. Il me semble qu'on est bien dans ce cas d'usage.
Comme on essaye dans le mesure du possible de ne pas dupliquer les
fonctionnalités (un seul plugin par besoin, ....) au sein de la
communauté cela me semble du même registre lorsqu'on a besoin d'un
code tiers.ah oui, il faudrait que chaque utilisateur s'occupe de télécharger la librairie et de la mettre sur son serveur, ça résout le problème de la zone et du dépôt de la librairie, on contourne plus le formulaire de téléchargement, j'avais pas pensé à ça... on perd en facilité d'usage, mais c'est certainement préférable.
Dans certains cas cette solution n'est pas possible (téléchargement
par validation pas mail, captcha, licence, ....) dans ce cas on n'a
pas le choix. A mon sens (avis personnel) autant demander à la source
quand on peut avant et importer dans le svn en dernier recours.Km
Super idée de plugin, le rendre générique a d'autre que materials serait encrore mieux du coup 
ptet des idées ou pistes a prendre dans cette implémentation de l'API fontello pour drupal
https://www.drupal.org/project/fontello
https://www.drupal.org/project/icon
la source de discussion Possible API Integration? · Issue #134 · fontello/fontello · GitHub
De mon coté, j'etais parti sur un plugin qui listait les svg présents dans un dossier symbols/ des plugins actifs et permettait de les sélectionner pour générer un svg/sprite de symbols ou defs , mais le problème reste identique a ta proposition, il faut que les svg soient présent sur le serveur.
Dans mon cas ça va car je reçoit les icones depuis des fichiers sketch ou similaires, ou un mélange entre plusieurs set d'icones, donc une surcharge depuis un skel de icon-agenda.svg par exemple m'allais bien… j'admet que pour un outil orienté rédacteur-trice ce n'est pas user-friendly.
--
Bonne journée
Arnaud B. (Mist. GraphX)
Le 27/06/2019 à 14:46, Mist. GraphX a écrit :
De mon coté, j'etais parti sur un plugin qui listait les svg présents
dans un dossier symbols/ des plugins actifs et permettait de les
sélectionner pour générer un svg/sprite de symbols ou defs , mais le
problème reste identique a ta proposition, il faut que les svg soient
présent sur le serveur.
piste complètement différente pour la méthode d'utilisation: quid de
mettre le code des SVG dans une table fournie par le plugin? (même
principe que les coordonnées géographiques des communes/départements
fournis par certain plugins).
Du coup leur intégration se fait "inline" dans l'article ou autre objet
éditorial et ça permettrait de pouvoir facilement les indexer, mettre
des titres, commentaires, crédits, associer avec des objet éditoriaux...
et plein d'autres bricolages sympas.
Ca ne règle pas le problème des licences bien sûr...
cy_altern
Le 27/06/2019 à 15:02, cy_altern a écrit :
piste complètement différente pour la méthode d'utilisation: quid de
mettre le code des SVG dans une table fournie par le plugin? (même
principe que les coordonnées géographiques des communes/départements
fournis par certain plugins).
Du coup leur intégration se fait "inline" dans l'article ou autre objet
éditorial et ça permettrait de pouvoir facilement les indexer, mettre
des titres, commentaires, crédits, associer avec des objet éditoriaux...
et plein d'autres bricolages sympas.
est-ce qu'on pourrait imaginer un plugin qui puisse piocher dans les images que l'utilisateur mettrait dans lib/svg par exemple ?
quelles que soient les images, on pourrait les mettre en base et les utiliser ensuite comme on veut, ce serait juste un extracteur de svg ?
--
----
chan
Bonjour,
est-ce qu’on pourrait imaginer un plugin qui puisse piocher dans les images que l’utilisateur mettrait dans lib/svg par exemple ?
quelles que soient les images, on pourrait les mettre en base et les utiliser ensuite comme on veut, ce serait juste un extracteur de svg ?
donc je suis en train de prendre cette solution, j’ai pas encore fini et je mettrai ça sur la zone prochainement.
Par contre je voudrais retirer complètement materialicons de la zone, puisque c’est pas la bonne voie.
Est-ce que je fais un svn rm ou alors est-ce qu’un root fais un rm -r sur le répertoire ?
Salut
Commiter c'est commité.
Il n'y aura pas d'action admin, il te faut bien faire un svn rm.
L'historique sera toujours là.
On peut jouer à l'admin dans des cas très spécifique et encore il faut
au moins que ce soit le dernier commit de l'historique.
Km
ok, voilà qui est fait