Re: [spip-dev] SPIP 4 et la compat des plugins

2021-05-08 Par sujet Eric Lupinacci
Re,


Le sam. 8 mai 2021 à 09:50, Maïeul Rouquette  a écrit :

>
> Je suis plutot d'accord avec la logique de branchement proposé, même si
> je ne suis pas sur qu'il soit pertinent de reduire les branches
> existantes. A voir.
>

 Je n'ai jamais considéré comme une bonne pratique d'avoir des branches qui
se chevauchent en termes de compatibilité. Dans ce cas laquelle choisir ?
Je pense qu'il faut toujours tirer les gens à installer les versions les
plus récentes qui seront dès lors plus à jour et plus fiables.
Dans notre cas, l'intérêt est aussi d'avoir une branche du plugin qui
devient obsolète au même titre que la version spip (spip < 3.2).

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 et la compat des plugins

2021-05-08 Par sujet Maïeul Rouquette

Le 07.05.21 à 16:54, Eric Lupinacci a écrit :

Hello,

Je commence à mettre à jour la compat des plugins que je maintiens mais 
je me pose pas mal de questions.
En outre, je vois passer des mises à jour sur d'autres plugins et on est 
pas très raccord sur la stratégie à adopter.
Je me dis que ça serait bien de définir quelques recommandations pour 
éviter la joyeuse kermesse à la fin...




Je suis plutot d'accord avec la logique de branchement proposé, même si 
je ne suis pas sur qu'il soit pertinent de reduire les branches 
existantes. A voir.

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] SPIP 4 et la compat des plugins

2021-05-08 Par sujet Eric Lupinacci
Hello,


Le ven. 7 mai 2021 à 23:44, RastaPopoulos  a écrit :

> 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.
>
>
+1
prefixe ou prefixe_logo me parait suffisant surtout que comme je l'ai déjà
dit, nous ne ferons pas disparaître l'attribut logo dans la spip 4.0.

Pouvez-vous maintenant donner votre avis sur la logique de branchement
proposée car c'est quand même le sujet principal du fil.
Merci.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 et la compat des plugins

2021-05-07 Par sujet RastaPopoulos
Le 07/05/2021 à 20:06, tcharlss a écrit :
> 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.

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.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 et la compat des plugins

2021-05-07 Par sujet Eric Lupinacci
Re,


Le ven. 7 mai 2021 à 20:06, tcharlss  a écrit :

>
> > 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_.svg me semblait rester simple et
> assez logique.
>

On peut essayer de rester dans la logique existante.
prefixe_logo_plugin.svg ou prefixe_logo.svg ça me parait suffisant.
Et maintenant ça serait bien de revenir au propos principal du fil qui est
la compat :)

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 et la compat des plugins

2021-05-07 Par sujet tcharlss


Le 07/05/2021 à 19:55, Matthieu Marcillaud a écrit :
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_.svg me semblait rester simple et 
assez logique.

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 et la compat des plugins

2021-05-07 Par sujet Matthieu Marcillaud

Le 07/05/2021 à 19:41, Bruno Bergot a écrit :

Hop,

Le 07/05/2021 à 19:36, tcharlss a écrit :

Juste prefixe.svg c'est garanti qu'à un moment ça va collisionner.



Claro, newsletter.svg/png à la racine d'un dossier squelettes et paf !



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.
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 et la compat des plugins

2021-05-07 Par sujet Eric Lupinacci
Le ven. 7 mai 2021 à 19:41, Bruno Bergot  a écrit :

>
> Claro, newsletter.svg/png à la racine d'un dossier squelettes et paf !
>

On en était à newsletter_logo.svg.
Vous pensez que c'est vraiment un problème ?

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 et la compat des plugins

2021-05-07 Par sujet Bruno Bergot

Hop,

Le 07/05/2021 à 19:36, tcharlss a écrit :

Juste prefixe.svg c'est garanti qu'à un moment ça va collisionner.



Claro, newsletter.svg/png à la racine d'un dossier squelettes et paf !

++
b_b
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] SPIP 4 et la compat des plugins

2021-05-07 Par sujet tcharlss

Le 07/05/2021 à 19:00, Eric Lupinacci a écrit :
Non il n'y a pas de différence à partir du moment où on définit un 
nommage obligatoire pour un plugin.
Je pense que s' il existe des cas tordus ils ne devraient pas être 
très nombreux et donc sûrement gérables.

Le but est de simplifier.
Donc pour moi le choix est soit prefixe.svg soit prefixe_logo.svg.
Et pour les cas tordus on gérera ça à la cool.

++
Eric


Mais, hum, heu...
Les conflits ne viendront pas forcément de plugins sur des dépôts dont 
on connaît le code.
Ils viendront des répertoires squelettes des gens, où ils mettent leurs 
assets, avec tous les noms d'images possibles.


À partir du moment où les logos des plugins sont à la racine, il y a 
forcément conflit possible si c'est des noms communs, ce qui n'était pas 
le cas quand ils était au fin fond d'un sous-répertoire themes/spip/images.


Il ne s'agit pas juste de trouver un nommage logique et raccord avec ce 
qui se fait pour les fichier php.

Il s'agit d'éviter par avance les conflits possibles.
Juste prefixe.svg c'est garanti qu'à un moment ça va collisionner.

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 et la compat des plugins

2021-05-07 Par sujet Eric Lupinacci
Le ven. 7 mai 2021 à 18:41, tcharlss  a écrit :

> Les fichiers php et les images ça n'est pas les mêmes contraintes : les
> plugins ou les gens sont libres de ranger et nommer les images destinées au
> site public comme bon leur semble, il n'y a rien d'imposé.
> Moi le doute de conflit c'est plutôt par rapport à ça : quelqu'un qui
> aurait placé toutes ses images en vrac à la racine dans son dossier
> squelettes. Et quand bien même c'est pas super, il/elle aurait bien le
> droit.
> C'est dans ce sens que ça serait plutôt à nous d'anticiper pour pas
> collusionner.
>
Non il n'y a pas de différence à partir du moment où on définit un nommage
obligatoire pour un plugin.
Je pense que s' il existe des cas tordus ils ne devraient pas être très
nombreux et donc sûrement gérables.
Le but est de simplifier.
Donc pour moi le choix est soit prefixe.svg soit prefixe_logo.svg.
Et pour les cas tordus on gérera ça à la cool.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 et la compat des plugins

2021-05-07 Par sujet tcharlss


Le 07/05/2021 à 18:24, Eric Lupinacci a écrit :


Oui mais là je ne suis pas trop d'accord.
C'est comme si on disait que prefixe_options pourrait être utilisé 
autrement.
A partir du moment où pour l'instant il est toujours possible de 
donner un nom quelconque et que le paquet possède toujours l'attribut 
je pense que ce sera aux plugins de s'adapter si contact_logo ou autre 
ont été utilisés hors logo.


On pourra faire ça tranquillement.
Et ensuite l'attribut logo pourra disparaître.

++
Eric


Les fichiers php et les images ça n'est pas les mêmes contraintes : les 
plugins ou les gens sont libres de ranger et nommer les images destinées 
au site public comme bon leur semble, il n'y a rien d'imposé.
Moi le doute de conflit c'est plutôt par rapport à ça : quelqu'un qui 
aurait placé toutes ses images en vrac à la racine dans son dossier 
squelettes. Et quand bien même c'est pas super, il/elle aurait bien le 
droit.
C'est dans ce sens que ça serait plutôt à nous d'anticiper pour pas 
collusionner.


___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 et la compat des plugins

2021-05-07 Par sujet Eric Lupinacci
Yo,



Le ven. 7 mai 2021 à 17:49, tcharlss  a écrit :

> Je crois que la remarque d'erational reste valable avec cette option, ça
> ferait aussi des noms d'images possiblement très courants comme
> contact_logo.svg, home_logo.svg, etc.
>
> Sinon par exemple plugin_.svg ?
>
Oui mais là je ne suis pas trop d'accord.
C'est comme si on disait que prefixe_options pourrait être utilisé
autrement.
A partir du moment où pour l'instant il est toujours possible de donner un
nom quelconque et que le paquet possède toujours l'attribut je pense que ce
sera aux plugins de s'adapter si contact_logo ou autre ont été utilisés
hors logo.

On pourra faire ça tranquillement.
Et ensuite l'attribut logo pourra disparaître.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 et la compat des plugins

2021-05-07 Par sujet tcharlss

Le 07/05/2021 à 17:34, Eric Lupinacci a écrit :


Oui c'est pas idiot.
J'avais proposé un truc comme ça mais Rasta m'a convaincu d'abandonner 
le complément du préfixe.
Si on devait le faire je pense qu'il faut garder la logique habituelle 
à savoir prefixe_logo.svg comme prefixe_options.php.


++
Eric


Je crois que la remarque d'erational reste valable avec cette option, ça 
ferait aussi des noms d'images possiblement très courants comme 
contact_logo.svg, home_logo.svg, etc.


Sinon par exemple plugin_.svg ?


___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 et la compat des plugins

2021-05-07 Par sujet Eric Lupinacci
Re,


Le ven. 7 mai 2021 à 17:28, erational  a écrit :

> logo-contact.svp c'est aussi très courant 
>
> peut-être prendre "svp" comme préfixe (mi-troll mi-raisin) ?
> svp-saisies.svg
>
>
> Le 07/05/2021 à 17:23, tcharlss a écrit :
>
> Le 07/05/2021 à 16:54, Eric Lupinacci a écrit :
>
> 3- passer le logo à la racine du plugin avec un nom prefixe.svg à partir
> de 3.2
>
> Un doute sur ce point : il serait pas plus prudent de faire plutôt
> logo-.svg ?
> Parceque si des plugins ont des préfixes super génériques, on pourrait se
> retrouver avec des home.svg, login.svg ou je sais pas quoi à la racine, des
> conflits possibles en perspective.
>
> Oui c'est pas idiot.
J'avais proposé un truc comme ça mais Rasta m'a convaincu d'abandonner le
complément du préfixe.
Si on devait le faire je pense qu'il faut garder la logique habituelle à
savoir prefixe_logo.svg comme prefixe_options.php.

++
Eric





> ___
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/irc://irc.freenode.net/spip
>
>
> --
> _https://www.erational.org
>
> ___
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 et la compat des plugins

2021-05-07 Par sujet erational

logo-contact.svp c'est aussi très courant 

peut-être prendre "svp" comme préfixe (mi-troll mi-raisin) ?
svp-saisies.svg


Le 07/05/2021 à 17:23, tcharlss a écrit :

Le 07/05/2021 à 16:54, Eric Lupinacci a écrit :
3- passer le logo à la racine du plugin avec un nom prefixe.svg à 
partir de 3.2


Un doute sur ce point : il serait pas plus prudent de faire plutôt 
logo-.svg ?
Parceque si des plugins ont des préfixes super génériques, on pourrait 
se retrouver avec des home.svg, login.svg ou je sais pas quoi à la 
racine, des conflits possibles en perspective.



___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


--
_
https://www.erational.org

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 et la compat des plugins

2021-05-07 Par sujet tcharlss

Le 07/05/2021 à 16:54, Eric Lupinacci a écrit :
3- passer le logo à la racine du plugin avec un nom prefixe.svg à 
partir de 3.2


Un doute sur ce point : il serait pas plus prudent de faire plutôt 
logo-.svg ?
Parceque si des plugins ont des préfixes super génériques, on pourrait 
se retrouver avec des home.svg, login.svg ou je sais pas quoi à la 
racine, des conflits possibles en perspective.


___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] spip 4 - retour d'usage

2021-05-06 Par sujet nicod_

Le 06/05/2021 à 12:36, tcharlss a écrit :
Pour la nomenclature, je sais pas. Si le conteneur extérieur peut rester 
un .choix de base, ça simplifierait pour les styles.


div.choix.choix_inline
   span.sous-choix
     label
     input
   span.sous-choix
    label
    input

Par exemple ?


https://git.spip.net/spip-contrib-extensions/saisies/src/branch/conteneur_inline/saisies/conteneur_inline.html 
?


--
nicod_
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] spip 4 - retour d'usage

2021-05-06 Par sujet Cerdic
Sorry, sorry, je sais que tu as fais pour le mieux avec les infos que tu avais, 
pardon de la formulation.

Et effectivement ta proposition de choix.choix_inline>.sous-choix (ou 
.choix-item ?) semble bien aussi pour gérer les cas où l’on veut mettre les 
choix en ligne dans un bloc .choix

--
Cédric
Le 6 mai 2021 à 12:36 +0200, tcharlss , a écrit :
> Le 06/05/2021 à 11:56, Cerdic a écrit :
> > Ah oui et en effet ils n’étaient pas stylé spécifiquement auparavant,
> > utilisant un très moche  pour gérer l'espacement
> >
> > Clairement ce « [ ] Oui [ ] Non » est un très mauvais pattern en terme
> > d’accessibilité, et gagnerait à être remplacé par une case à cocher
> > explicite
> >
> > Mais sinon on peut en effet proposer un markup spécifique, soit un
> > .choix-multiples qui du coup aurait le stylage proposé par Tcharlss,
> > soit des .choix-inline regroupés dans un .groupe-choix ?
> > Ou même simplement des .choix regroupés dans un .groupe-choix-flex ou
> > quelque chose du genre ? (qui serait un flex row avec wrap auto)
>
> +10 pour supprimer les oui/non au profit de simples case à cocher
>
> Sinon pour les choix multiples, il y a aussi Media qui met largeur +
> hauteur dans un même .choix par exemple.
>
> Pour la nomenclature, je sais pas. Si le conteneur extérieur peut rester
> un .choix de base, ça simplifierait pour les styles.
>
> div.choix.choix_inline
>   span.sous-choix
>     label
>     input
>   span.sous-choix
>    label
>    input
>
> Par exemple ?
>
> Et enfin bon, puisque ça a été subtilement suggéré je me sens obligé de
> répondre : je me garde bien d'ajouter des choses à la charte tout seul
> dans mon coin sans en parler avant, ou d'inventer des cas d'utilisation.
> Les styles répondent aux choses qui étaient clairement définies dans la
> charte (celle de 3.2), et pour les cas moins clairs comme les .choix et
> bien oui, des fois il faut inférer une partie des règles en fonction de
> ce qu'on a devant les yeux, les formulaires de la dist en l'occurence.
> On peut se tromper mais merci de ne pas immédiatement me prêter des
> intentions que j'ai jamais eues.
>
>
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] spip 4 - retour d'usage

2021-05-06 Par sujet Jean-Christophe Villeneuve

Bon j'ai recodé le formulaire
https://git.spip.net/spip-contrib-squelettes/escal/src/branch/master/formulaires/configurer_escal_layout.html#L44

Pouvez-vous me dire s'il y a encore des choses qui ne vont pas avant que 
je m'attaque aux autres ?


PS : vraiment dommage qu'on ne puisse pas mettre les .choix en ligne 
plutôt qu'en colonne


JC




Le 06/05/2021 à 11:18, Jean-Christophe Villeneuve a écrit :

Ah cool, en effet ça va bien m'aider ce plugin dev !

JC

Le 06/05/2021 à 10:26, RastaPopoulos a écrit :

Le 06/05/2021 à 09:08, Jean-Christophe Villeneuve a écrit :

Merci pour ces explications, je vais essayer de corriger mon code.
Où peut-on trouver cette fameuse charte des forms dans spip ?
Yop c'est dans le plugin "Dev" (fourni par l'équipe noyau, dans 
l'orga /spip


Quand tu l'installes tu as alors accès à des pages de charte de l'admin.

Mais sinon sur le site spip.net il y a une page sur la normalisation 
des formulaires. Cependant elle n'est pas très à jour… :)




___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] spip 4 - retour d'usage

2021-05-06 Par sujet nicod_

Le 06/05/2021 à 11:56, Cerdic a écrit :
Clairement ce « [ ] Oui [ ] Non » est un très mauvais pattern en terme 
d’accessibilité, et gagnerait à être remplacé par une case à cocher 
explicite


Absolument pas, ce sont deux choix d'UX totalement différents, il faut 
bien choisir en connaissance de cause et en fonction du contexte.



If questions are like this:
"Subscribe to newsletter?", then its definitely checkbox. If its missed, then, 
they don't miss something important
If questions are like this:
"Should we email you the order details for record?" then definitely go for 
radios.


https://www.sarasoueidan.com/blog/one-checkbox-or-two-radio-buttons/
https://www.nngroup.com/articles/checkboxes-vs-radio-buttons/

--
nicod_
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] spip 4 - retour d'usage

2021-05-06 Par sujet tcharlss

Le 06/05/2021 à 11:56, Cerdic a écrit :
Ah oui et en effet ils n’étaient pas stylé spécifiquement auparavant, 
utilisant un très moche  pour gérer l'espacement


Clairement ce « [ ] Oui [ ] Non » est un très mauvais pattern en terme 
d’accessibilité, et gagnerait à être remplacé par une case à cocher 
explicite


Mais sinon on peut en effet proposer un markup spécifique, soit un 
.choix-multiples qui du coup aurait le stylage proposé par Tcharlss, 
soit des .choix-inline regroupés dans un .groupe-choix ?
Ou même simplement des .choix regroupés dans un .groupe-choix-flex ou 
quelque chose du genre ? (qui serait un flex row avec wrap auto)


+10 pour supprimer les oui/non au profit de simples case à cocher

Sinon pour les choix multiples, il y a aussi Media qui met largeur + 
hauteur dans un même .choix par exemple.


Pour la nomenclature, je sais pas. Si le conteneur extérieur peut rester 
un .choix de base, ça simplifierait pour les styles.


div.choix.choix_inline
  span.sous-choix
    label
    input
  span.sous-choix
   label
   input

Par exemple ?

Et enfin bon, puisque ça a été subtilement suggéré je me sens obligé de 
répondre : je me garde bien d'ajouter des choses à la charte tout seul 
dans mon coin sans en parler avant, ou d'inventer des cas d'utilisation.
Les styles répondent aux choses qui étaient clairement définies dans la 
charte (celle de 3.2), et pour les cas moins clairs comme les .choix et 
bien oui, des fois il faut inférer une partie des règles en fonction de 
ce qu'on a devant les yeux, les formulaires de la dist en l'occurence. 
On peut se tromper mais merci de ne pas immédiatement me prêter des 
intentions que j'ai jamais eues.



___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] spip 4 - retour d'usage

2021-05-06 Par sujet Maïeul Rouquette

Le 06.05.21 à 11:18, Jean-Christophe Villeneuve a écrit :

Ah cool, en effet ça va bien m'aider ce plugin dev !

JC



sinon il y aussi le plugin "saisies" qui permet de juste déclarer le 
sens semantique de des saisies qu'on veut avoir et laisser le plugin se 
charger du marrkup :p

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] spip 4 - retour d'usage

2021-05-06 Par sujet Maïeul Rouquette

Le 06.05.21 à 11:48, RastaPopoulos a écrit :

Le 06/05/2021 à 11:37, Cerdic a écrit :

La démarche c’est pas que les css par défaut des formulaires doivent styler 
tous les cas inimaginables, mais bien uniquement les cas de la charte et 
ensuite les cas particuliers sont stylés comme des cas particuliers (formulaire 
par formulaire)


Oui mais le cas oui/non dans un même choix… c'est un cas du core ! :)

Du coup je suppute que tcharlss pensait bien faire en se disant : si c'est 
utilisé par le core, c'est que ça doit être prévu dans les styles.

Mais on peut bien sûr parfaitement décider que c'est le core qui faisait 
n'importe quoi et prenait des libertés, et donc : corriger le core.

C'est ma préférence aussi, ce qui évite d'ajouter un concept rare en plus de 
groupe de choix, on corrige les forms de contenus d'articles, etc qui ont des 
oui/non dans la même ligne. D'ailleurs tcharlss disait que ça serait 
possiblement bien de les corriger pour des cases à cocher, mieux que des 
oui/non généralement, mais bon faut voir l'implication en terme de chaines.

moi j'ai envie de dire : quitte à rompre des choses, simplifions et 
virons les incohérences du core :)


Idéalement la case à cocher c'est mieux (même si pas tjr possible), 
reste à voir quoi faire du côté des chaines de langue.

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] spip 4 - retour d'usage

2021-05-06 Par sujet Cerdic
Ah oui et en effet ils n’étaient pas stylé spécifiquement auparavant, utilisant 
un très moche  pour gérer l'espacement

Clairement ce « [ ] Oui [ ] Non » est un très mauvais pattern en terme 
d’accessibilité, et gagnerait à être remplacé par une case à cocher explicite

Mais sinon on peut en effet proposer un markup spécifique, soit un 
.choix-multiples qui du coup aurait le stylage proposé par Tcharlss, soit des 
.choix-inline regroupés dans un .groupe-choix ?
Ou même simplement des .choix regroupés dans un .groupe-choix-flex ou quelque 
chose du genre ? (qui serait un flex row avec wrap auto)

--
Cédric
Le 6 mai 2021 à 11:48 +0200, RastaPopoulos , a écrit :
> Le 06/05/2021 à 11:37, Cerdic a écrit :
> > La démarche c’est pas que les css par défaut des formulaires doivent styler 
> > tous les cas inimaginables, mais bien uniquement les cas de la charte et 
> > ensuite les cas particuliers sont stylés comme des cas particuliers 
> > (formulaire par formulaire)
>
> Oui mais le cas oui/non dans un même choix… c'est un cas du core ! :)
>
> Du coup je suppute que tcharlss pensait bien faire en se disant : si c'est 
> utilisé par le core, c'est que ça doit être prévu dans les styles.
>
> Mais on peut bien sûr parfaitement décider que c'est le core qui faisait 
> n'importe quoi et prenait des libertés, et donc : corriger le core.
>
> C'est ma préférence aussi, ce qui évite d'ajouter un concept rare en plus de 
> groupe de choix, on corrige les forms de contenus d'articles, etc qui ont des 
> oui/non dans la même ligne. D'ailleurs tcharlss disait que ça serait 
> possiblement bien de les corriger pour des cases à cocher, mieux que des 
> oui/non généralement, mais bon faut voir l'implication en terme de chaines.
>
> --
> RastaPopoulos
>
> ___
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] spip 4 - retour d'usage

2021-05-06 Par sujet RastaPopoulos
Le 06/05/2021 à 11:37, Cerdic a écrit :
> La démarche c’est pas que les css par défaut des formulaires doivent styler 
> tous les cas inimaginables, mais bien uniquement les cas de la charte et 
> ensuite les cas particuliers sont stylés comme des cas particuliers 
> (formulaire par formulaire)

Oui mais le cas oui/non dans un même choix… c'est un cas du core ! :)

Du coup je suppute que tcharlss pensait bien faire en se disant : si c'est 
utilisé par le core, c'est que ça doit être prévu dans les styles.

Mais on peut bien sûr parfaitement décider que c'est le core qui faisait 
n'importe quoi et prenait des libertés, et donc : corriger le core.

C'est ma préférence aussi, ce qui évite d'ajouter un concept rare en plus de 
groupe de choix, on corrige les forms de contenus d'articles, etc qui ont des 
oui/non dans la même ligne. D'ailleurs tcharlss disait que ça serait 
possiblement bien de les corriger pour des cases à cocher, mieux que des 
oui/non généralement, mais bon faut voir l'implication en terme de chaines.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] spip 4 - retour d'usage

2021-05-06 Par sujet Cerdic
Je comprends pas l’argument sur les choix oui/non collé : il y a pas de cas 
officiels et supportés avec un radio oui et un radio non dans un même .choix

Cf la charte 3.2
https://git.spip.net/spip/dev/src/branch/master/formulaires/charter.html#L113
le choix « oui » est dans un .choix, le choix « non » est dans un autre .choix,

Et ici c’est une case à cocher « Oui » dans un .choix avec un hidden « non » 
pour avoir la valeur non si on coche pas
https://git.spip.net/spip/dev/src/branch/master/formulaires/charter.html#L130
il y a donc un seul choix dans le .choix et c’est la seule chose à styler

Les gens qui mettent éventuellement pleins de trucs dans un .choix, y compris 
plusieurs choix (radio, case), doivent alors gérer d’ajouter du css pour gérer 
leurs marge ou leurs alignement ou que sais-je

Sur la mediabox, par exemple j’ai rusé en faisant un .choix pour regrouper et 
dedans plusieurs sous .choix sur lesquels j’enleve la bordure
https://git.spip.net/spip/mediabox/src/branch/master/inc/mediabox.php#L84


La démarche c’est pas que les css par défaut des formulaires doivent styler 
tous les cas inimaginables, mais bien uniquement les cas de la charte et 
ensuite les cas particuliers sont stylés comme des cas particuliers (formulaire 
par formulaire)

--
Cédric
Le 6 mai 2021 à 11:06 +0200, tcharlss , a écrit :
> En résumé :
>
> * Je vais retirer la règle trop stricte. On se contente de l'habillage
> extérieur (la bordure) sans présumer de ce qu'il y a dedans
> * Les .choix des forms de config en oui/non vont être à nouveau collés,
> pour ces cas-là peut-être faudrait-il en effet introduire un
> .groupe-choix ou autre (uniquement pour mettre une marge entre 2 paires
> inputs+label successives)
> * Escal prend d'énormes libertés avec la charte :)
>
> Le 06/05/2021 à 10:26, RastaPopoulos a écrit :
> >
> > Yop c'est dans le plugin "Dev" (fourni par l'équipe noyau, dans l'orga /spip
> >
> > Quand tu l'installes tu as alors accès à des pages de charte de l'admin.
> >
> > Mais sinon sur le site spip.net il y a une page sur la normalisation des 
> > formulaires. Cependant elle n'est pas très à jour… :)
> >
> ___
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] spip 4 - retour d'usage

2021-05-06 Par sujet Jean-Christophe Villeneuve

Oui j'ai codé ça sans connaitre la charte.
Je vais recoder tout ça ... y'a du taf !

JC

Le 06/05/2021 à 11:06, tcharlss a écrit :

En résumé :

* Je vais retirer la règle trop stricte. On se contente de l'habillage 
extérieur (la bordure) sans présumer de ce qu'il y a dedans
* Les .choix des forms de config en oui/non vont être à nouveau 
collés, pour ces cas-là peut-être faudrait-il en effet introduire un 
.groupe-choix ou autre (uniquement pour mettre une marge entre 2 
paires inputs+label successives)

* Escal prend d'énormes libertés avec la charte :)

Le 06/05/2021 à 10:26, RastaPopoulos a écrit :


Yop c'est dans le plugin "Dev" (fourni par l'équipe noyau, dans 
l'orga /spip


Quand tu l'installes tu as alors accès à des pages de charte de l'admin.

Mais sinon sur le site spip.net il y a une page sur la normalisation 
des formulaires. Cependant elle n'est pas très à jour… :)



___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] spip 4 - retour d'usage

2021-05-06 Par sujet Jean-Christophe Villeneuve

Ah cool, en effet ça va bien m'aider ce plugin dev !

JC

Le 06/05/2021 à 10:26, RastaPopoulos a écrit :

Le 06/05/2021 à 09:08, Jean-Christophe Villeneuve a écrit :

Merci pour ces explications, je vais essayer de corriger mon code.
Où peut-on trouver cette fameuse charte des forms dans spip ?

Yop c'est dans le plugin "Dev" (fourni par l'équipe noyau, dans l'orga /spip

Quand tu l'installes tu as alors accès à des pages de charte de l'admin.

Mais sinon sur le site spip.net il y a une page sur la normalisation des 
formulaires. Cependant elle n'est pas très à jour… :)



___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] spip 4 - retour d'usage

2021-05-06 Par sujet tcharlss

En résumé :

* Je vais retirer la règle trop stricte. On se contente de l'habillage 
extérieur (la bordure) sans présumer de ce qu'il y a dedans
* Les .choix des forms de config en oui/non vont être à nouveau collés, 
pour ces cas-là peut-être faudrait-il en effet introduire un 
.groupe-choix ou autre (uniquement pour mettre une marge entre 2 paires 
inputs+label successives)

* Escal prend d'énormes libertés avec la charte :)

Le 06/05/2021 à 10:26, RastaPopoulos a écrit :


Yop c'est dans le plugin "Dev" (fourni par l'équipe noyau, dans l'orga /spip

Quand tu l'installes tu as alors accès à des pages de charte de l'admin.

Mais sinon sur le site spip.net il y a une page sur la normalisation des 
formulaires. Cependant elle n'est pas très à jour… :)


___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] spip 4 - retour d'usage

2021-05-06 Par sujet RastaPopoulos
Le 06/05/2021 à 09:08, Jean-Christophe Villeneuve a écrit :
> Merci pour ces explications, je vais essayer de corriger mon code.
> Où peut-on trouver cette fameuse charte des forms dans spip ?

Yop c'est dans le plugin "Dev" (fourni par l'équipe noyau, dans l'orga /spip

Quand tu l'installes tu as alors accès à des pages de charte de l'admin.

Mais sinon sur le site spip.net il y a une page sur la normalisation des 
formulaires. Cependant elle n'est pas très à jour… :)

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] spip 4 - retour d'usage

2021-05-06 Par sujet Jean-Christophe Villeneuve

Hello

Merci pour ces explications, je vais essayer de corriger mon code.
Où peut-on trouver cette fameuse charte des forms dans spip ?

JC

Le 05/05/2021 à 23:45, RastaPopoulos a écrit :

Le 05/05/2021 à 23:20, tcharlss a écrit :

Ça rentre dans la définition ? Charte, pas charte ?

Pour moi non, on appelle un choix un choix :p

Après entre les .choix on peut mettre des sortes d'intertitres ou des 
explications pourquoi pas mais pas 50 radios dans un même choix

Bon sachant que là en plus dans le lien d'escal je sais pas si t'as vu mais 
tout est DANS un div.explication en plus ! Là ça m'a l'air vraiment du grand 
n'importe quoi par rapport à la charte des forms :)
Ya même des .choix dans le .choix qui entoure tout…

.editer (encore en ul li en plus alors que ça fait des années que c'est plus 
des li)
   .explication
 texte intertitre à l'extérieur du .choix
 span.choix
   input label moult fois
   texte intertitre à l'intérieur
   input label moult
   texte intertitre
   .choix etc

Bref c'est grave WTF là :)


Là ça devrait être des fieldsets contenant des radios : c'est la norme 
consacrée pour être accessibles pour les radios désormais.

Et après des .editer n'ayant rien à voir pour les input text de largeur etc, 
qui n'ont aucun rapport avec les .choix radio.



___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] spip 4 - retour d'usage

2021-05-05 Par sujet RastaPopoulos
Le 05/05/2021 à 23:20, tcharlss a écrit :
> Ça rentre dans la définition ? Charte, pas charte ?

Pour moi non, on appelle un choix un choix :p

Après entre les .choix on peut mettre des sortes d'intertitres ou des 
explications pourquoi pas mais pas 50 radios dans un même choix

Bon sachant que là en plus dans le lien d'escal je sais pas si t'as vu mais 
tout est DANS un div.explication en plus ! Là ça m'a l'air vraiment du grand 
n'importe quoi par rapport à la charte des forms :) 
Ya même des .choix dans le .choix qui entoure tout…

.editer (encore en ul li en plus alors que ça fait des années que c'est plus 
des li)
  .explication
texte intertitre à l'extérieur du .choix
span.choix
  input label moult fois
  texte intertitre à l'intérieur
  input label moult
  texte intertitre
  .choix etc

Bref c'est grave WTF là :)


Là ça devrait être des fieldsets contenant des radios : c'est la norme 
consacrée pour être accessibles pour les radios désormais.

Et après des .editer n'ayant rien à voir pour les input text de largeur etc, 
qui n'ont aucun rapport avec les .choix radio.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] spip 4 - retour d'usage

2021-05-05 Par sujet tcharlss

Le 05/05/2021 à 22:59, RastaPopoulos a écrit :

De ce que j'ai compris de l'explication justement ya aucune règle pour 
l'intérieur des .choix, à part cette seule règle : c'est un seul choix dedans. 
Mais ensuite on peut mettre n'importe quoi, input, explication, hidden, image 
que sais-je


Oui mais le fait qu'on puisse mettre ce quon veut dedans, c'est une 
règle en soi.  C'est pas pour jouer sur les mots, figurez-vous qu'après 
il y a des gens qui doivent styler tout ça et savoir à quoi s'attendre 
:) Donc quelque chose à indiquer clairement dans la charte au niveau des 
exemples de .choix.


Ensuite le fait qu'il puisse n'y avoir qu'un seul choix dedans, je sais 
pas exactement ce que ça veut dire.
Par exemple pour les trucs en oui/non t'as 2 inputs dedans (la règle 
trop restrictive c'était pour ce cas d'ailleurs).
Dans l'exemple d'Escal donné par JC Villeneuve, t'as un seul .choix avec 
pleins d'inputs dedans, avec des sortes de "groupes" séparés par des 
 : 
https://git.spip.net/spip-contrib-squelettes/escal/src/branch/master/formulaires/configurer_escal_layout.html#L44

Ça rentre dans la définition ? Charte, pas charte ?


___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] spip 4 - retour d'usage

2021-05-05 Par sujet Jean-Christophe Villeneuve

En effet ça marche mieux avec un seul input par .choix

Merci !

JC

Le 05/05/2021 à 22:50, Jean-Christophe Villeneuve a écrit :

Ah mais c'est pas moi qui ai stylé ainsi, c'est spip !

Mais ok pour la suite, je vais essayé de coder plus proprement

JC


Le 05/05/2021 à 22:30, Cerdic a écrit :

Hello,

Ça me parait quand même louche de styler le 2n+1 et le 3n+3 child 
dans .choix :(


Je suppose que tu as voulu traiter le cas où on a juste un .choix et 
dedans une succession de input+label, mais c’est normalement pas un 
cas à traiter et ça me semble invasif et pas très robuste...


Quid du ou des input hidden dans un .choix qui viennent perturber le 
compteur comme ici

https://git.spip.net/spip/dev/src/branch/master/formulaires/charter.html#L132 ?

Je vois que c’est parce que vous avec voulu permettre le cas de « On 
met tous les choix dans un seul .choix » comme ici

https://git.spip.net/spip/dev/src/branch/dev/refacto_form_charter/formulaires/charter.html#L101
mais ça me parait pas pertinent ni robuste

Ce conteneur .choix a été introduit pour permettre justement 
d’identifier une unité semantique de choix, et qu’on puisse y mettre 
si besoin un markup un peu souple comme une explication, une image, 
ou que sais-je qui serais nécessaire dans des cas particuliers.


En présumant que le .choix est rempli de succession de label+input et 
uniquement ça on bloque à nouveau toute souplesse de balisage...


Il faut rester sur la convention .choix = 1 choix, en général composé 
d’un input+label, mais pas forcément uniquement.


Alternativement, si besoin pour certains cas de mise en forme, il 
faut introduire un .groupe-choix l’encadrant ?

Jusqu’ici ça n’avait pas été indispensable, mais pourquoi pas...

--
Cédric
Le 5 mai 2021 à 21:34 +0200, tcharlss , a 
écrit :


On peut voir le squelette du formulaire et une capture de ce que ça 
donnait avant ?

Et est-ce qu'il y a des CSS personnalisées ?

Ces règles s'appuient sur les cas connus et documentés de la charte 
des formulaires.


Le 05/05/2021 à 21:07, Jean-Christophe Villeneuve a écrit :

J'ai un souci d'affichage dans le privé

http://escal.ac-lyon.fr/spip4test/squelettes/Selection.png

J'ai un doute sur ces 2 règles css

.formulaire_spip .choix > :nth-child(2n+1) {
    margin-right: calc(var(--spip-form-padding-input-x) * 3/4);
}

et

.formulaire_spip .choix > :nth-child(3n+3), .formulaire_spip 
span.choix + span.choix {

    margin-left: var(--spip-form-spacing-x);
}



___
liste:https://listes.rezo.net/mailman/listinfo/spip-dev
doc:https://www.spip.net/
dev:https://core.spip.net/
irc://irc.freenode.net/spip

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip



___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] spip 4 - retour d'usage

2021-05-05 Par sujet RastaPopoulos
Le 05/05/2021 à 22:53, tcharlss a écrit :
> En tout ce qui est permis ou pas dans ces .choix est clairement à documenter 
> dans la charte.

De ce que j'ai compris de l'explication justement ya aucune règle pour 
l'intérieur des .choix, à part cette seule règle : c'est un seul choix dedans. 
Mais ensuite on peut mettre n'importe quoi, input, explication, hidden, image 
que sais-je

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] spip 4 - retour d'usage

2021-05-05 Par sujet tcharlss
Oui pour les .choix c'était un peu compliqué d'inférer ce qui était 
permis ou pas, en se basant uniquement sur les exemples de la charte et 
les utilisations dans la dist, ça semblait n'être que des successions 
d'inputs + labels (ou l'inverse).

Et donc la règle c'est pour mettre une marge entre les "paires".

Mais si dedans il peut y avoir n'importe quoi, en effet c'est trop 
restrictif.
Par contre ça veut dire que pour ces cas simples, on n'a aucun moyen de 
mettre ces marges.


En tout ce qui est permis ou pas dans ces .choix est clairement à 
documenter dans la charte.


Le 05/05/2021 à 22:30, Cerdic a écrit :

Hello,

Ça me parait quand même louche de styler le 2n+1 et le 3n+3 child dans 
.choix :(


Je suppose que tu as voulu traiter le cas où on a juste un .choix et 
dedans une succession de input+label, mais c’est normalement pas un 
cas à traiter et ça me semble invasif et pas très robuste...


Quid du ou des input hidden dans un .choix qui viennent perturber le 
compteur comme ici
https://git.spip.net/spip/dev/src/branch/master/formulaires/charter.html#L132 
 ?


Je vois que c’est parce que vous avec voulu permettre le cas de « On 
met tous les choix dans un seul .choix » comme ici
https://git.spip.net/spip/dev/src/branch/dev/refacto_form_charter/formulaires/charter.html#L101 


mais ça me parait pas pertinent ni robuste

Ce conteneur .choix a été introduit pour permettre justement 
d’identifier une unité semantique de choix, et qu’on puisse y mettre 
si besoin un markup un peu souple comme une explication, une image, ou 
que sais-je qui serais nécessaire dans des cas particuliers.


En présumant que le .choix est rempli de succession de label+input et 
uniquement ça on bloque à nouveau toute souplesse de balisage...


Il faut rester sur la convention .choix = 1 choix, en général composé 
d’un input+label, mais pas forcément uniquement.


Alternativement, si besoin pour certains cas de mise en forme, il faut 
introduire un .groupe-choix l’encadrant ?

Jusqu’ici ça n’avait pas été indispensable, mais pourquoi pas...


___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] spip 4 - retour d'usage

2021-05-05 Par sujet Jean-Christophe Villeneuve

Ah mais c'est pas moi qui ai stylé ainsi, c'est spip !

Mais ok pour la suite, je vais essayé de coder plus proprement

JC


Le 05/05/2021 à 22:30, Cerdic a écrit :

Hello,

Ça me parait quand même louche de styler le 2n+1 et le 3n+3 child dans 
.choix :(


Je suppose que tu as voulu traiter le cas où on a juste un .choix et 
dedans une succession de input+label, mais c’est normalement pas un 
cas à traiter et ça me semble invasif et pas très robuste...


Quid du ou des input hidden dans un .choix qui viennent perturber le 
compteur comme ici

https://git.spip.net/spip/dev/src/branch/master/formulaires/charter.html#L132 ?

Je vois que c’est parce que vous avec voulu permettre le cas de « On 
met tous les choix dans un seul .choix » comme ici

https://git.spip.net/spip/dev/src/branch/dev/refacto_form_charter/formulaires/charter.html#L101
mais ça me parait pas pertinent ni robuste

Ce conteneur .choix a été introduit pour permettre justement 
d’identifier une unité semantique de choix, et qu’on puisse y mettre 
si besoin un markup un peu souple comme une explication, une image, ou 
que sais-je qui serais nécessaire dans des cas particuliers.


En présumant que le .choix est rempli de succession de label+input et 
uniquement ça on bloque à nouveau toute souplesse de balisage...


Il faut rester sur la convention .choix = 1 choix, en général composé 
d’un input+label, mais pas forcément uniquement.


Alternativement, si besoin pour certains cas de mise en forme, il faut 
introduire un .groupe-choix l’encadrant ?

Jusqu’ici ça n’avait pas été indispensable, mais pourquoi pas...

--
Cédric
Le 5 mai 2021 à 21:34 +0200, tcharlss , a 
écrit :


On peut voir le squelette du formulaire et une capture de ce que ça 
donnait avant ?

Et est-ce qu'il y a des CSS personnalisées ?

Ces règles s'appuient sur les cas connus et documentés de la charte 
des formulaires.


Le 05/05/2021 à 21:07, Jean-Christophe Villeneuve a écrit :

J'ai un souci d'affichage dans le privé

http://escal.ac-lyon.fr/spip4test/squelettes/Selection.png 



J'ai un doute sur ces 2 règles css

.formulaire_spip .choix > :nth-child(2n+1) {
    margin-right: calc(var(--spip-form-padding-input-x) * 3/4);
}

et

.formulaire_spip .choix > :nth-child(3n+3), .formulaire_spip 
span.choix + span.choix {

    margin-left: var(--spip-form-spacing-x);
}



___
liste:https://listes.rezo.net/mailman/listinfo/spip-dev
doc:https://www.spip.net/
dev:https://core.spip.net/
irc://irc.freenode.net/spip

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] spip 4 - retour d'usage

2021-05-05 Par sujet Jean-Christophe Villeneuve

Ce que ça donne sur spip 3.2

http://escal.ac-lyon.fr/spip4test/squelettes/Selection2.png 



Le code est là

https://git.spip.net/spip-contrib-squelettes/escal/src/branch/master/formulaires/configurer_escal_layout.html

j'ai juste remplacé les


On peut voir le squelette du formulaire et une capture de ce que ça 
donnait avant ?

Et est-ce qu'il y a des CSS personnalisées ?

Ces règles s'appuient sur les cas connus et documentés de la charte 
des formulaires.


Le 05/05/2021 à 21:07, Jean-Christophe Villeneuve a écrit :

J'ai un souci d'affichage dans le privé

http://escal.ac-lyon.fr/spip4test/squelettes/Selection.png 



J'ai un doute sur ces 2 règles css

.formulaire_spip .choix > :nth-child(2n+1) {
    margin-right: calc(var(--spip-form-padding-input-x) * 3/4);
}

et

.formulaire_spip .choix > :nth-child(3n+3), .formulaire_spip 
span.choix + span.choix {

    margin-left: var(--spip-form-spacing-x);
}



___
liste:https://listes.rezo.net/mailman/listinfo/spip-dev
doc:https://www.spip.net/
dev:https://core.spip.net/
irc://irc.freenode.net/spip


___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] spip 4 - retour d'usage

2021-05-05 Par sujet Cerdic
Hello,

Ça me parait quand même louche de styler le 2n+1 et le 3n+3 child dans .choix :(

Je suppose que tu as voulu traiter le cas où on a juste un .choix et dedans une 
succession de input+label, mais c’est normalement pas un cas à traiter et ça me 
semble invasif et pas très robuste...

Quid du ou des input hidden dans un .choix qui viennent perturber le compteur 
comme ici
https://git.spip.net/spip/dev/src/branch/master/formulaires/charter.html#L132 ?

Je vois que c’est parce que vous avec voulu permettre le cas de « On met tous 
les choix dans un seul .choix » comme ici
https://git.spip.net/spip/dev/src/branch/dev/refacto_form_charter/formulaires/charter.html#L101
mais ça me parait pas pertinent ni robuste

Ce conteneur .choix a été introduit pour permettre justement d’identifier une 
unité semantique de choix, et qu’on puisse y mettre si besoin un markup un peu 
souple comme une explication, une image, ou que sais-je qui serais nécessaire 
dans des cas particuliers.

En présumant que le .choix est rempli de succession de label+input et 
uniquement ça on bloque à nouveau toute souplesse de balisage...

Il faut rester sur la convention .choix = 1 choix, en général composé d’un 
input+label, mais pas forcément uniquement.

Alternativement, si besoin pour certains cas de mise en forme, il faut 
introduire un .groupe-choix l’encadrant ?
Jusqu’ici ça n’avait pas été indispensable, mais pourquoi pas...

--
Cédric
Le 5 mai 2021 à 21:34 +0200, tcharlss , a écrit :
> On peut voir le squelette du formulaire et une capture de ce que ça donnait 
> avant ?
> Et est-ce qu'il y a des CSS personnalisées ?
> Ces règles s'appuient sur les cas connus et documentés de la charte des 
> formulaires.
> Le 05/05/2021 à 21:07, Jean-Christophe Villeneuve a écrit :
> > J'ai un souci d'affichage dans le privé
> >
> > http://escal.ac-lyon.fr/spip4test/squelettes/Selection.png
> >
> > J'ai un doute sur ces 2 règles css
> >
> > .formulaire_spip .choix > :nth-child(2n+1) {
> >     margin-right: calc(var(--spip-form-padding-input-x) * 3/4);
> > }
> >
> > et
> >
> > .formulaire_spip .choix > :nth-child(3n+3), .formulaire_spip span.choix + 
> > span.choix {
> >     margin-left: var(--spip-form-spacing-x);
> > }
> >
> >
> >
> > ___
> > liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> > doc: https://www.spip.net/
> > dev: https://core.spip.net/
> > irc://irc.freenode.net/spip
> ___
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] spip 4 - retour d'usage

2021-05-05 Par sujet tcharlss
On peut voir le squelette du formulaire et une capture de ce que ça 
donnait avant ?

Et est-ce qu'il y a des CSS personnalisées ?

Ces règles s'appuient sur les cas connus et documentés de la charte des 
formulaires.


Le 05/05/2021 à 21:07, Jean-Christophe Villeneuve a écrit :

J'ai un souci d'affichage dans le privé

http://escal.ac-lyon.fr/spip4test/squelettes/Selection.png 



J'ai un doute sur ces 2 règles css

.formulaire_spip .choix > :nth-child(2n+1) {
    margin-right: calc(var(--spip-form-padding-input-x) * 3/4);
}

et

.formulaire_spip .choix > :nth-child(3n+3), .formulaire_spip 
span.choix + span.choix {

    margin-left: var(--spip-form-spacing-x);
}



___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-05-05 Par sujet RastaPopoulos
Le 29/04/2021 à 21:26, Arnaud Martin a écrit :
> La grosse limite de tout faire avec Compositions, pour moi, c’est que ça va 
> forcément laisser le choix d’utiliser un squelette qui n’a pas été prévu pour 
> être généralisé à l’ensemble du site. 

Eh non, depuis le début Compositions a une option quand t'es webmestre : 
"Verrouiller la composition". Dans ce cas ya que la personne s'occupant de la 
maintenance technique qui va choisir la composition, et les autres personnes 
qui utilisent le site au quotidien admins et rédacs ne pourront plus rien 
modifier pour cette rubrique.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4

2021-05-03 Par sujet cam.lafit
Hello

Il y eu un projet spip_intervallaire pour prendre en charge la
hiérarchie imbriquée.
Un aspect technique bloquait le fonctionnement à l'époque, les transactions.

Depuis cela est maintenant presque par défaut sur la plupart des bases
de données, cela pourrait donc être possible sans remettre en cause la
logique de base actuelle de SPIP.

Km

PS : Elle est belle cette nouvelle version \o/
Merci

Le 03/05/2021 à 19:11, Gildas Cotomale a écrit :
> Le lun. 3 mai 2021 à 16:27, Matthieu Marcillaud a écrit :
>>
>> Le 03/05/2021 à 16:06, Pierre-Jean Colliot a écrit :
>>>
>>> Bonjour,
>>>
>>> Je rebondis sur ce sujet car il met le doigt sur un point auquel je
>>> pense depuis quelques années et qui a modifié mes pratiques avec
>>> l'abandon des articles au profit de l'objet rubrique sur la quarantaine
>>> de sites que je gère.
>>
> Ça n'en a pas l'air, mais cela montre que SPIP évolue au point de
> permettre cette flexibilité inimaginable en version 1.2.x par exemple.
> 
>> C'est une idée qui a déjà eu des discussions, il y a peut être un ticket
>> là dessus pour avoir des articles hiérarchisés, où un article peut être
>> le descendant d'un autre. Je crois que ça s'est arrêté à des discussions
>> et qu'il n'y a pas eu de Proof of concept en plugin.
>>
> J'ai l'impression qu'il n'y a pas beaucoup d'usagers de polyhiérarchie
> (enfin je ne sais pas si ça répond vraiment à la problématique)
> 
> Depuis la version 2 il y a la possibilité d'avoir des objets répondant
> aux besoins spécifiques mais rien n'a encore émergé comme solution
> générique largement testée.
> 
>> Donc non : pour SPIP 4, c'est mort clairement ! On est à stabiliser /
>> terminer toutes les modifs qu'en rajouter d'autres… Surtout une énorme
>> comme celle là.
>>
>> Il faut d'abord tester ce genre de choses en plugin. Et quid de la
>> migration de la BDD et des squelettes ? Ça ouvre un champ de questions
>> assez immense :)
>>
> Tout à fait.
> ___
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip
> 
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4

2021-05-03 Par sujet Gildas Cotomale
Le lun. 3 mai 2021 à 16:26, Pierre-Jean Colliot a écrit :
>
>
> Bonjour,
>
Salutations,

> Je rebondis sur ce sujet car il met le doigt sur un point auquel je pense 
> depuis quelques années et qui a modifié mes pratiques avec l'abandon des 
> articles au profit de l'objet rubrique sur la quarantaine de sites que je 
> gère.
>
>
> Sémantiquement, un site est avant tout composé de pages.
>
Sémantiquement, c'est un abus de langage car les pages viennent du
monde de l'édition papier… La preuve en est que ce que tu considères
comme « page » sera vu comme plusieurs pages en face et ces derniers
seront parfois appelés « écran » ;-)

> On a des pages et des sous-pages (rubriques et sous-rubriques sur SPIP). La 
> notion d'article n'a pas vraiment de sens (c'est peut-être une composition 
> graphique et structurelle à part, mais c'est avant tout une page...). Et 
> surtout, la notion d'article induit une terminaison qui n'est pas forcement 
> souhaitée, ni évolutive.
>
La notion de « sous-pages » n'est connu que dans des milieux
spécialisés et je ne connaissais personnellement pas.

> vive-les-chats.tld/chat-bengal/alimentation(.html)
>
> Et mince, je suis bloqué trois mois plus tard car au final mon "dossier" sur 
> l'alimentation doit se développer avec
>
> vive-les-chats.tld/chat-bengal/alimentation/bio/
> vive-les-chats.tld/chat-bengal/alimentation/chasse/
>
>
> Du coup je me tape des redirections 301, je fais des copier-coller, etc pour 
> tout remettre d'équerre...
>

Ce que tu décris, de mon point de vue, est un problème qui se posera
aussi avec des sous-pages et sous-sous-pages et sur-pages : tu as
choisi, je pense une structure d'URL arborescente et une arborescence
qui chaque tous les quatre matins. (mais il ne faut pas que le système
respecte le choix que tu as fait ? et il y a d'autres choix
d'adressage)
>
> Et pour rebondir un peu plus sur le message de Luis : les pages d'un site 
> peuvent avoir ou ne pas avoir d'auteurs ou tout autre champ réservé 
> arbitrairement aux articles ou bien aux rubriques.
> En fait peu importe qu'il s'agisse de rubriques ou d'articles ou de brèves... 
> Il s'agit de la même chose, de pages, avec du contenu, des auteurs ou non, 
> des soustitres ou non...
>
Ça fait un bout de temps déjà que pratiquement plus rien n'est imposé
: lors d'une installation toute neuve on est invité à configurer ce
qu'on aimerait avoir ou pas comme champs. J'ai peut être rêvé en
croyant voir cela ? :-)
>
> Discalimer : il ne s'agit là que d'un avis personnel dont la subjectivité 
> pourra froisser certaines sensibilités, son auteur s'excuse de par avance des 
> tourments occasionnés.
>
Pas de souci, j'émets aussi un avis mais avec l'envie d'échanger et
mieux comprendre les problématiques rencontrées et les solutions
proposées ailleurs (et donc d'apprendre de nouvelles visions) :-)
>
> Bien à vous,
>
>
> Pierre-Jean
>
>
>
> 
> De : Luis Speciale 
> Envoyé : lundi 3 mai 2021 15:01:49
> À : spip-dev@rezo.net
> Objet : [spip-dev] SPIP 4
>
> Ah qu'elle est belle. Quelle aventure, bon sang !
>
> Et tant qu'on y est, peut-on considérer de donner aux rubriques les
> mêmes champs que les articles ? Ou aux articles la capacité d'avoir des
> petits ? Ou c'est pas intelligent ?
>
>
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4

2021-05-03 Par sujet Gildas Cotomale
Le lun. 3 mai 2021 à 16:27, Matthieu Marcillaud a écrit :
>
> Le 03/05/2021 à 16:06, Pierre-Jean Colliot a écrit :
> >
> > Bonjour,
> >
> > Je rebondis sur ce sujet car il met le doigt sur un point auquel je
> > pense depuis quelques années et qui a modifié mes pratiques avec
> > l'abandon des articles au profit de l'objet rubrique sur la quarantaine
> > de sites que je gère.
>
Ça n'en a pas l'air, mais cela montre que SPIP évolue au point de
permettre cette flexibilité inimaginable en version 1.2.x par exemple.

> C'est une idée qui a déjà eu des discussions, il y a peut être un ticket
> là dessus pour avoir des articles hiérarchisés, où un article peut être
> le descendant d'un autre. Je crois que ça s'est arrêté à des discussions
> et qu'il n'y a pas eu de Proof of concept en plugin.
>
J'ai l'impression qu'il n'y a pas beaucoup d'usagers de polyhiérarchie
(enfin je ne sais pas si ça répond vraiment à la problématique)

Depuis la version 2 il y a la possibilité d'avoir des objets répondant
aux besoins spécifiques mais rien n'a encore émergé comme solution
générique largement testée.

> Donc non : pour SPIP 4, c'est mort clairement ! On est à stabiliser /
> terminer toutes les modifs qu'en rajouter d'autres… Surtout une énorme
> comme celle là.
>
> Il faut d'abord tester ce genre de choses en plugin. Et quid de la
> migration de la BDD et des squelettes ? Ça ouvre un champ de questions
> assez immense :)
>
Tout à fait.
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4

2021-05-03 Par sujet Perline-Spip

Une autre question qui se pose c'est à qui est destiné SPIP.
Qui va s'en servir ?
Et donc, quelle(s) facilité(s) pour cet·te utilisateur·rice ?
Ce que décrit Pierre-Jean est pour le·a programmeu·euse SPIP.
Mais au bout de la chaîne comment faire comprendre les méandres de cette chaîne 
très variable.
SPIP a été conçu pour faire un journal, et tout le monde sait ce qu'est une rubrique 'Monde, France, Société..." et 
dedans un article (long, avec chapeau et sous-titre) ou une brève (pas d'auteur, rapide à lire).


C'est pour cela que nombre d'entre nous ont contourné la structure initiale pour utiliser, effectivement, les objets et 
en faire ce qu'on veut !
Mais de là à ériger cette technique en postulat de base, mérite de considérer tou·tes les utilisateur·rices au final 
pour ne pas en exclure.


Matthieu Marcillaud a écrit le 03/05/2021 à 16:25 :

Le 03/05/2021 à 16:06, Pierre-Jean Colliot a écrit :


Bonjour,

Je rebondis sur ce sujet car il met le doigt sur un point auquel je pense depuis quelques années et qui a modifié mes 
pratiques avec l'abandon des articles au profit de l'objet rubrique sur la quarantaine de sites que je gère.


C'est une idée qui a déjà eu des discussions, il y a peut être un ticket là dessus pour avoir des articles 
hiérarchisés, où un article peut être le descendant d'un autre. Je crois que ça s'est arrêté à des discussions et 
qu'il n'y a pas eu de Proof of concept en plugin.


Donc non : pour SPIP 4, c'est mort clairement ! On est à stabiliser / terminer toutes les modifs qu'en rajouter 
d'autres… Surtout une énorme comme celle là.


Il faut d'abord tester ce genre de choses en plugin. Et quid de la migration de la BDD et des squelettes ? Ça ouvre un 
champ de questions assez immense :)


MM.


--
Fin du message end - Signature
Perline

s...@perline.org – http://perline.org/

Ce message est couvert par le secret de la correspondance
(art. 226-15 et 432-9 du Code pénal)


___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4

2021-05-03 Par sujet Matthieu Marcillaud

Le 03/05/2021 à 16:06, Pierre-Jean Colliot a écrit :


Bonjour,

Je rebondis sur ce sujet car il met le doigt sur un point auquel je 
pense depuis quelques années et qui a modifié mes pratiques avec 
l'abandon des articles au profit de l'objet rubrique sur la quarantaine 
de sites que je gère.


C'est une idée qui a déjà eu des discussions, il y a peut être un ticket 
là dessus pour avoir des articles hiérarchisés, où un article peut être 
le descendant d'un autre. Je crois que ça s'est arrêté à des discussions 
et qu'il n'y a pas eu de Proof of concept en plugin.


Donc non : pour SPIP 4, c'est mort clairement ! On est à stabiliser / 
terminer toutes les modifs qu'en rajouter d'autres… Surtout une énorme 
comme celle là.


Il faut d'abord tester ce genre de choses en plugin. Et quid de la 
migration de la BDD et des squelettes ? Ça ouvre un champ de questions 
assez immense :)


MM.



___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4

2021-05-03 Par sujet Pierre-Jean Colliot

Bonjour,

Je rebondis sur ce sujet car il met le doigt sur un point auquel je pense 
depuis quelques années et qui a modifié mes pratiques avec l'abandon des 
articles au profit de l'objet rubrique sur la quarantaine de sites que je gère.


Sémantiquement, un site est avant tout composé de pages.

On a des pages et des sous-pages (rubriques et sous-rubriques sur SPIP). La 
notion d'article n'a pas vraiment de sens (c'est peut-être une composition 
graphique et structurelle à part, mais c'est avant tout une page...). Et 
surtout, la notion d'article induit une terminaison qui n'est pas forcement 
souhaitée, ni évolutive.

vive-les-chats.tld/chat-bengal/alimentation(.html)

Et mince, je suis bloqué trois mois plus tard car au final mon "dossier" sur 
l'alimentation doit se développer avec

vive-les-chats.tld/chat-bengal/alimentation/bio/
vive-les-chats.tld/chat-bengal/alimentation/chasse/


Du coup je me tape des redirections 301, je fais des copier-coller, etc pour 
tout remettre d'équerre...


Et pour rebondir un peu plus sur le message de Luis : les pages d'un site 
peuvent avoir ou ne pas avoir d'auteurs ou tout autre champ réservé 
arbitrairement aux articles ou bien aux rubriques.
En fait peu importe qu'il s'agisse de rubriques ou d'articles ou de brèves... 
Il s'agit de la même chose, de pages, avec du contenu, des auteurs ou non, des 
soustitres ou non...


Discalimer : il ne s'agit là que d'un avis personnel dont la subjectivité 
pourra froisser certaines sensibilités, son auteur s'excuse de par avance des 
tourments occasionnés.


Bien à vous,


Pierre-Jean




De : Luis Speciale 
Envoyé : lundi 3 mai 2021 15:01:49
À : spip-dev@rezo.net
Objet : [spip-dev] SPIP 4

Ah qu'elle est belle. Quelle aventure, bon sang !

Et tant qu'on y est, peut-on considérer de donner aux rubriques les
mêmes champs que les articles ? Ou aux articles la capacité d'avoir des
petits ? Ou c'est pas intelligent ?


___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
SPIP Core (Forge de développement)
core.spip.net
Redmine



irc://irc.freenode.net/spip
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-05-03 Par sujet jeanmarie

Salut Matthieu,

merci pour ces modifs.

                jeanmarie


Le 02/05/2021 à 22:22, Matthieu Marcillaud a écrit :

Le 30/04/2021 à 10:03, jeanmarie a écrit :


*Compagnon*


[...]

Comme évoqué par d'autres dans la discussion, ajouter la possibilité 
de le désactiver pour soi et


Au fait, sur cette 4.0.0-alpha, c'est fait : sur le message (de 
compagnon) de bienvenue de l'accueil, un bouton permet de désactiver 
le compagnon pour soi.



tant qu'à y être, pour tout le monde si ça mange pas de pain serait 
super.


Ça c'était déjà disponible dans la configuration du compagnon !


Aussi, rendre les boutons qui ferment les boites d'infos (Merci / 
J’ai compris ! / Parfait...) pourraient être plus explicites (avec 
une croix pour ? des styles plus boutons ? ...) pour que les gens les 
ferment (la plupart de mes utilisateur·rices reste avec pendant des 
mois avant que je leur dise qu'ils sont désactivables. > ça mérite un 
ticket ça ?


Ça aussi c'est fait sur la 4.0.0-alpha : il y a une croix en haut à 
droite visible sur chaque boite du compagnon.


___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-05-02 Par sujet Matthieu Marcillaud

Le 30/04/2021 à 10:03, jeanmarie a écrit :


*Compagnon*


[...]

Comme évoqué par d'autres dans la discussion, ajouter la possibilité de 
le désactiver pour soi et


Au fait, sur cette 4.0.0-alpha, c'est fait : sur le message (de 
compagnon) de bienvenue de l'accueil, un bouton permet de désactiver le 
compagnon pour soi.


, tant qu'à y être, pour tout le monde si ça

mange pas de pain serait super.


Ça c'était déjà disponible dans la configuration du compagnon !


Aussi, rendre les boutons qui ferment les boites d'infos (Merci / J’ai 
compris ! / Parfait...) pourraient être plus explicites (avec une croix 
pour ? des styles plus boutons ? ...) pour que les gens les ferment (la 
plupart de mes utilisateur·rices reste avec pendant des mois avant que 
je leur dise qu'ils sont désactivables. > ça mérite un ticket ça ?


Ça aussi c'est fait sur la 4.0.0-alpha : il y a une croix en haut à 
droite visible sur chaque boite du compagnon.


MM.
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-05-01 Par sujet Matthieu Marcillaud

Le 01/05/2021 à 02:37, Matthieu Marcillaud a écrit :

Le 30/04/2021 à 20:18, Matthieu Marcillaud a écrit :


Aide


Il semble qu'il faut conserver le plugin au moins pour pouvoir gérer 
l'aide des raccourcis typographique 


[...]

Pour une première proposition en fichiers...

https://git.spip.net/spip/aide/pulls/2


On va a priori intégrer cette proposition (en fr uniquement pour 
l'instant) dans l'alpha 4.0… histoire que les gens puissent tester et 
faire des retours.


+ cacher le lien "aide" du bandeau qui ne mène à rien avec cette 
proposition pour le moment mais "plus tard peut être, un jour, lointain" 
pourrait revenir et amener sur une url externe tel que rediger.spip.net 
par exemple.


MM.
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-05-01 Par sujet Eric Lupinacci
Yo,

Le ven. 30 avr. 2021 à 20:18, Matthieu Marcillaud  a
écrit :

> Le 30/04/2021 à 19:04, Bruno Bergot a écrit :
> J'ai enlevé donc les plugins qui n'étaient pas discutés.
>

+1

Squelettes par rubriques
> 
> Je pense qu'on peut proposer "squelettes par rubriques" uniquement en
> plugin et l'enlever des plugins-dist. La fonctionnalité ne disparait
> pas, et peut être réactivée donc facilement au besoin.
>
>
+1



>
> Compagnon
> -
> On peut peut être ajouter un bouton supplémentaire sur le message de
> bienvenue d'un auteur sur l'accueil (et celui-ci seulement) qui dit en
> gros (formulation sympa à trouver) "Je connais SPIP ! (ne plus
> m'afficher le compagnon nulle part)"
>

+1
Je pense qu'il très chouette ce plugin et peut être utilisé plus
intensément.
Je l'ai utilisé récemment pour prévenir de lancer une action de mise à jour
de la base qu'il n'était pas possible de faire automatiquement.
Et franchement les reproches sur l'UI sont assez incompréhensibles pour moi.


>
>
> Aide
> 
>
> Il semble qu'il faut conserver le plugin au moins pour pouvoir gérer
> l'aide des raccourcis typographique ; potentiellement uniquement
> ceux-là. Mais ça veut dire qu'il faut… revoir le plugin pour que ça soit
> à jour. (je dirais : gasp ! faut un peu de temps quoi !)
>

+1.
Le mieux serait de proposé une alternative simple pour les raccourcis.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-30 Par sujet Matthieu Marcillaud

Le 30/04/2021 à 20:18, Matthieu Marcillaud a écrit :


Aide


Il semble qu'il faut conserver le plugin au moins pour pouvoir gérer 
l'aide des raccourcis typographique 


[...]

Pour une première proposition en fichiers...

https://git.spip.net/spip/aide/pulls/2

MM
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-30 Par sujet Bruno Bergot

Hop,

Le 30/04/2021 à 21:03, Cerdic a écrit :

Dans tous les cas perdons pas de vu le kiss : on va pas se lancer dans une 
refonte complète du plugin aide *pour cette release* : même si on est tous 
d’accord qu’il faudrait le faire dans l’absolu, ne tombons pas dans le piège du 
« ah mais on fait juste ça en plus et puis… » dans 4 ans on est encore à 
essayer de faire la release.



Je te rejoins complètement sur cet argument :)


Donc soit on laisse le plugin aide faute de mieux, soit on le vire complètement 
et on a un truc simple et rapide pour juste les raccourcis SPIP, mais bon bref 
vous voyez l’idée.




Le truc simple serait peut-être de sortir les pages d'aide "de leur 
cage" dans les squelettes des spip.net et de faire qu'elles soient 
affichées comme des pages classiques du site avec son habillage et pas 
comme c'est le cas maintenant, cf :


https://www.spip.net/aide/?aide=raccourcis#contenu-aide

Mais ça péterait l'aide des sites déjà en place :\

Donc le plus "kiss" serait de virer le bouzin complètement et de fournir 
un simple lien vers la page ci-dessus pour le cas qui nous intéresse, le 
lien ? à côté du porte-plume.



La release sera jamais parfaite, on aura jamais fini, donc tenons nous au 
calendrier prévu, et ce qui est pas fait là le sera dans la prochaine (ou dans 
10 ans si c’est pas si grave…)



+1 pour l'argument de la perfection, release often tout ça, et justement 
le nouveau cycle de release devrait nous permettre d'éviter de 
corriger/améliorer ça pas trop lentement :)


++
b_b
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-30 Par sujet tcharlss

Le 30/04/2021 à 10:03, jeanmarie a écrit :


*Compagnon*

Sur le principe, je me dis que c'est utile et accueillant (tendre 
comme SPIP, quoi :) ).
Sur l'utilisation au quotidien, je trouve ça chiant (en tant que 
personne qui utilise intensément l'espace privé) de l'avoir dans les 
pattes tout le temps et devoir le fermer au cas par cas.


Moi après réflexion je pense que les compagnons font partie des choses à 
garder, sur le principe c'est une très bonne idée.


Je repense aux fois où j'ai utilisé d'autres applis web pour la 1ère 
fois : celles qui proposaient des choses un peu similaires faisaient 
vraiment une très bonne 1ère impression. Il ne s'agissait pas de 
messages qui popaient un peu partout, mais d'un « tour » à travers 
l'interface pour guider les gens qui découvrent. En quelques étapes on 
était familiarisé avec le gros oeuvre, sans avoir à quitter le 
backoffice pour lire la doc. On pouvait décliner la 1ère fois et on en 
entendait plus parler.


Donc sans doute des choses à repenser pour ne pas embêter les gens qui 
connaissent déjà l'interface, mais en soi les compagnons, c'est bien 
pratique.


___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-30 Par sujet nicod_

Le 30/04/2021 à 21:03, Cerdic a écrit :
La release sera jamais parfaite, on aura jamais fini, donc tenons nous 
au calendrier prévu, et ce qui est pas fait là le sera dans la prochaine 
(ou dans 10 ans si c’est pas si grave…)


+1

Il n'y a pas consensus pour le retirer, donc mettons ce chantier (super 
intéressant) de côté pour l'instant.


--
nicod_
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] SPIP 4 =?utf-8?Q?=E2=80=94_?=proposition d'enlever quelques plugins-dist par défaut

2021-04-30 Par sujet Cerdic
Dans tous les cas perdons pas de vu le kiss : on va pas se lancer dans une 
refonte complète du plugin aide *pour cette release* : même si on est tous 
d’accord qu’il faudrait le faire dans l’absolu, ne tombons pas dans le piège du 
« ah mais on fait juste ça en plus et puis… » dans 4 ans on est encore à 
essayer de faire la release.

Donc soit on laisse le plugin aide faute de mieux, soit on le vire complètement 
et on a un truc simple et rapide pour juste les raccourcis SPIP, mais bon bref 
vous voyez l’idée.

La release sera jamais parfaite, on aura jamais fini, donc tenons nous au 
calendrier prévu, et ce qui est pas fait là le sera dans la prochaine (ou dans 
10 ans si c’est pas si grave…)

--
Cédric
Le 30 avr. 2021 à 20:46 +0200, Bruno Bergot , a écrit :
> Hop,
>
> Le 30/04/2021 à 20:18, Matthieu Marcillaud a écrit :
>
> > Oui, j'aimerais bien en .md… mais on n'a pas librairie dans le core pour
> > traduire le .md ensuite en html… donc… soit on a ajoute une… soit on le
> > fait pas comme ça ! Et l'avantage du .spip, c'est que tu appliques
> > propre() et tu peux montrer en direct des exemples (pour les tableaux
> > notamment).
> >
>
> Ha ben je répondais justement à une remarque d'arno en privé il ya
> quelques minutes sur ce point :
>
> Oui, avec le plugin MD on peut baliser le type de syntaxe dans un texte
> qui en utilise plusieurs, cf :
>
> https://git.spip.net/spip-contrib-extensions/markdown
>
> Après on peut aussi versionner un txt qui utilise la syntaxe SPIP, mais
> c'est hachement moins pratique pour le partager, l'éditer en ligne ou
> dans un éditeur, bref, la syntaxe SPIP a "un peu" moins d'outil à dispo
> que MD ;)
>
> ++
> b_b
> ___
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-30 Par sujet Bruno Bergot

Hop,

Le 30/04/2021 à 20:18, Matthieu Marcillaud a écrit :

Oui, j'aimerais bien en .md… mais on n'a pas librairie dans le core pour 
traduire le .md ensuite en html… donc… soit on a ajoute une… soit on le 
fait pas comme ça ! Et l'avantage du .spip, c'est que tu appliques 
propre() et tu peux montrer en direct des exemples (pour les tableaux 
notamment).




Ha ben je répondais justement à une remarque d'arno en privé il ya 
quelques minutes sur ce point :


Oui, avec le plugin MD on peut baliser le type de syntaxe dans un texte 
qui en utilise plusieurs, cf :


https://git.spip.net/spip-contrib-extensions/markdown

Après on peut aussi versionner un txt qui utilise la syntaxe SPIP, mais 
c'est hachement moins pratique pour le partager, l'éditer en ligne ou 
dans un éditeur, bref, la syntaxe SPIP a "un peu" moins d'outil à dispo 
que MD ;)


++
b_b
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-30 Par sujet nicod_

Le 30/04/2021 à 20:18, Matthieu Marcillaud a écrit :

Compagnon
-

Il est mignon, mais il gène les utilisateurs aguerris. Certaines 
personnes ne voient pas que les messages peuvent se fermer.


Il est mignon comme tu dis, mais je crois que c'est une fausse bonne 
idée depuis le début.
C'était un palliatif à une UI soit disant mal comprise, mais le remède 
est finalement encore plus mal compris :)


--
nicod_
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-30 Par sujet Matthieu Marcillaud

Le 30/04/2021 à 20:18, Matthieu Marcillaud a écrit :

[...]

Aide


[...]
Une proposition serait d'intégrer cette documentation d'aide directement 
dans le plugin. 


Ah oui, au fait, il y avait eu 
https://blog.smellup.net/spip.php?rubrique11 qui parlait de l'aide.


MM.
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-30 Par sujet Matthieu Marcillaud

Le 30/04/2021 à 19:04, Bruno Bergot a écrit :
[...]

J'arrive un peu tard, mais je suis pour le retrait de toute la liste 
proposée.


J'ai enlevé donc les plugins qui n'étaient pas discutés.

Il reste les cas donc de :

- squelettes par rubriques
- aide
- compagnon

Je vais tacher de faire un résumé de différentes discussions rapidement 
à leur sujet.



Squelettes par rubriques


Il est pratique, notamment simple pour débuter.

Contrairement à Composition, il fait une recherche sur toutes les 
inclusions pour vérifier s'il existe un =12.html ou -12.html ou .en.html 
et en remontant aussi la hiérarchie de rubriques le cas échéant. Le fait 
que ça s'applique sur toutes les inclusions est gourmand. Compositions 
ne le fait que sur certains blocs (notamment ceux déclarés à z-core).


Effectivement les 2 plugins n'ont pas exactement les mêmes 
caractéristiques (Compositions est visible dans l'espace privé par exemple)


Je pense qu'on peut proposer "squelettes par rubriques" uniquement en 
plugin et l'enlever des plugins-dist. La fonctionnalité ne disparait 
pas, et peut être réactivée donc facilement au besoin.



Compagnon
-

Il est mignon, mais il gène les utilisateurs aguerris. Certaines 
personnes ne voient pas que les messages peuvent se fermer.


J'ai amélioré l'UI des boites de compagnon pour mieux voir que ça se 
ferme. Ce point est réglé.


On peut peut être ajouter un bouton supplémentaire sur le message de 
bienvenue d'un auteur sur l'accueil (et celui-ci seulement) qui dit en 
gros (formulation sympa à trouver) "Je connais SPIP ! (ne plus 
m'afficher le compagnon nulle part)"



Aide


Il semble qu'il faut conserver le plugin au moins pour pouvoir gérer 
l'aide des raccourcis typographique ; potentiellement uniquement 
ceux-là. Mais ça veut dire qu'il faut… revoir le plugin pour que ça soit 
à jour. (je dirais : gasp ! faut un peu de temps quoi !)


Une proposition serait d'intégrer cette documentation d'aide directement 
dans le plugin. Ça ne facilite pas les traductions : car ce serait des 
fichiers (en chaîne de langue c'est trop difficile à gérer vu la 
longueur des textes).


Par exemple dans un répertoire : aide/fr_FR/raccourcis_liens.spip (ou 
.md j'y reviens après)


Il y aurait une déclaration explicite de "groupe" d'aide, et d'entrées, 
qui passerait par un pipeline. Par exemple (très rapide, juste pour l'idée)


$liste = [
'raccourcis' => [
'titre' => _T('aide:groupe_raccourcis_typo'),
'entrees' => [
'liens' => [
'titre' 
=>_T('aide:groupe_raccourcis_typo_liens'),
'fichier' => 'raccourcis_liens.spip'
]
]
];

L'exemple à l'inconvénient de devoir déclarer les titres et l'ordre (des 
groupes, des entrées), mais c'est probablement plus simple et clair que 
de l'extraire des fichiers automatiquement.


Les aides éventuelles, appelleraient par exemple #AIDER{raccourcis} (le 
nom du groupe), qui ouvrirait la modale (comme actuellement) avec en 
colonne le titre de chaque entrée (mais uniquement de ce groupe 
'raccourcis'), en en contenu le texte de chaque entrée (pris dans les 
fichiers .spip).


En tout cas c'est une piste possible.

Le lien "aide" du bandeau, pourrait ouvrir un menu avec tous les groupes 
déclarés (si tel est le cas), ou disparaitre...


C'est des réflexions live… désolé.

J'y pensais hier, mais Arno m'a devancé, la seule aide utile est il me 
semble cette des raccourcis typo du porte-plume. Et je me dis qu'on 
pourrait facilement la garder à jour et la traduire en la déportant dans 
un fichier MD inclus dans le plugin, ce qui ne bloque en rien l'envie de 
compléter ou traduire celle-ci, et en plus aurait l'avantage de 
versionner la doc en synchro avec la branche en cours.


Oui, j'aimerais bien en .md… mais on n'a pas librairie dans le core pour 
traduire le .md ensuite en html… donc… soit on a ajoute une… soit on le 
fait pas comme ça ! Et l'avantage du .spip, c'est que tu appliques 
propre() et tu peux montrer en direct des exemples (pour les tableaux 
notamment).


MM.
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-30 Par sujet Bruno Bergot

Hop,

Le 29/04/2021 à 17:07, Matthieu Marcillaud a écrit :

Nous sommes quelques un·es à proposer qu'on retire des plugins-dist 
certains plugins (*ils seront toujours disponibles via la gestion des 
plugins* pour les réactiver — ça ne veut pas dire qu'ils ne seront plus 
maintenus par la communauté)





J'arrive un peu tard, mais je suis pour le retrait de toute la liste 
proposée.


J'y pensais hier, mais Arno m'a devancé, la seule aide utile est il me 
semble cette des raccourcis typo du porte-plume. Et je me dis qu'on 
pourrait facilement la garder à jour et la traduire en la déportant dans 
un fichier MD inclus dans le plugin, ce qui ne bloque en rien l'envie de 
compléter ou traduire celle-ci, et en plus aurait l'avantage de 
versionner la doc en synchro avec la branche en cours.


++
b_b
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-30 Par sujet nicod_

Le 30/04/2021 à 08:59, Eric Lupinacci a écrit :
Ou alors faire comme pour Saisies et sa page d'explication accessible 
via un menu.
Là on aurait juste une page qui rappelle les raccourcis et qui serait 
accessible par le ?.
On pourrait même imaginer que certains plugins qui ajoutent des 
raccourcis puissent s'y insérer pour lister les leurs.


Ça, ce serait vraiment pas mal, beaucoup plus utile même.

--
nicod_
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] SPIP 4 — proposition d'enlever squelettes par rubriques

2021-04-30 Par sujet JLuc

Le 30/04/2021 à 10:03, jeanmarie a écrit :

*Ok pour la liste des plugins supprimés.*
Y compris *Squelettes**par rubriques* qui induit des pratiques pas forcément idéales (je m'inclus dedans) et couteuse en 
perf (je fais confiance au dev sur ce point).
Il est avantageusement remplaçable par Compositions 


Il y a des arguments théoriques en faveur de composition,
du même ordre me semble t il que ceux qui favorisent A2A ou Selections
au détriment des motclés.

Squelette par rubrique c'est simple (avantage) mais c'est rustique (pas 
sémantique),
et par ailleurs ça a un coût en terme de performance.

Mais composition aussi a un coût en performance pour son fonctionnement.
Et ce coût n'est il pas plus important encore pour les compositions
vu le grand raffinement et la complexité des possibles réglages contextuels ?

Pour ma part je n'ai pas encore eu l'occasion d'apprécier Composition,
mais par contre j'en ai perçu c'est des gênes :
- ça altère les tables et y ajoutant une colonne (même quand c'est inutile).
- l'usage des compositions altère les squelettes polyvalents (z par exemple)
en ajoutant des arguments superfétatoires aux inclusions.

Parfois je fais sans le plugin des trucs qui ressemblent aux Compositions,
et je ne vois pas bien ce que le plugin m'apporterait en plus.

Compositions est certainement la bonne solution dans certains cas,
mais quand squelettes-par-rubriques est adapté,
je pense que c'est plus adapté et mieux que Compositions.

Je veux pas non lus dire qu'il faut garder squelettes par rubriques (sujet du 
thread)
car c'est pas utiles à tous les sites et car il y a des alternatives,
mais peut on remettre Compositions à sa juste et relative place (sujet du 
vendredi ?) ?

JL


et, pour combler le besoin légitime d'Arno de pouvoir verrouiller 
par composition (aujourd'hui, c'est tout ou rien), ça serait une fonctionnalité à ajouter dedans. Pour le reste, 
l'intérêt de la suppression me parait l’emporter sur le garder en plugins-dist.


*Compagnon*

Sur le principe, je me dis que c'est utile et accueillant (tendre comme SPIP, 
quoi :) ).
Sur l'utilisation au quotidien, je trouve ça chiant (en tant que personne qui utilise intensément l'espace privé) de 
l'avoir dans les pattes tout le temps et devoir le fermer au cas par cas.


Comme évoqué par d'autres dans la discussion, ajouter la possibilité de le désactiver pour soi et, tant qu'à y être, 
pour tout le monde si ça mange pas de pain serait super.


Aussi, rendre les boutons qui ferment les boites d'infos (Merci / J’ai compris ! / Parfait...) pourraient être plus 
explicites (avec une croix pour ? des styles plus boutons ? ...) pour que les gens les ferment (la plupart de mes 
utilisateur·rices reste avec pendant des mois avant que je leur dise qu'ils sont désactivables. > ça mérite un ticket ça ?


Et pour finir, *merci à toutes les personnes qui ont contribué à ces grandes avancées *ces derniers temps, c'est 
vraiment une super dynamique pour la communauté !


                 jeanmarie





___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-30 Par sujet Eric Lupinacci
Yop,

Le ven. 30 avr. 2021 à 10:05, Matthieu Marcillaud  a
écrit :

>
> > Ou alors faire comme pour Saisies et sa page d'explication accessible
> > via un menu.
>
> Mouais : y a déjà un lien "aide" dans le bandeau. Et ça irait dans quel
> menu ? (en statut rédacteur)
>
>
Non aucun menu comme je le dis après, juste le ?. Je parle juste de la
présentation si on ne garde pas la popup.


> > Là on aurait juste une page qui rappelle les raccourcis et qui serait
> > accessible par le ?.
>
> Alors… je me demandais si le bouton [?] n'était présent qu'en tant
> qu'icone du porte plume (et plus ailleurs), si ça serait suffisant ?
>

Ca pourrait vu qu'on ne s'en sert que là à priori.


>
> > On pourrait même imaginer que certains plugins qui ajoutent des
> > raccourcis puissent s'y insérer pour lister les leurs.
>
> Certes. Enfin encore une fois il faut gérer les traductions également.
> Ça peut être dans les fichiers de langue des plugins aussi.
> Et si tu veux lier des images ou montrer le résultat du code, c'est plus
> difficile je suppose en chaine de langue.
>

Une idée rapide serait un tableau avec un index pour chaque raccourci.
Chaque index contient les items de langue qui expliquent le raccourci. Ce
qui permet de facilement traduire cette aide.
Et le tableau de raccourci peut être complété par un pipeline pour les
plugins qui en rajoutent.
Au moins ça fait une aide complète sur un sujet majeur et facilement
maintenable et évolutive.

C'est déconnant ?

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-30 Par sujet Matthieu Marcillaud

Le 30/04/2021 à 08:59, Eric Lupinacci a écrit :



Le ven. 30 avr. 2021 à 08:50, Arnaud Martin > a écrit :



Concernant l’aide, en fait il y a *une* seule page qui est
franchement utile: la page des «raccourcis typographiques». Parce
que même après 20 ans à faire du SPIP quotidiennement, je connais
pas les fusions de cases des tableaux, ni les appels de notes de bas
de page.


Oui, entièrement d'accord : l'aide c'est surtout utile pour les 
raccourcis typo. Il y a plein de subtilités / possibilités facilement 
oubliées.


Si la présentation actuelle de la popin d'aide est conservée, le menu de 
gauche pourrait contenir (à la place de l'actuel) les différentes 
parties des raccourcis typo (paragraphes, liens, notes, tableaux, ...) 
(des ancres vers le bon endroit du contenu central), ce qui serait un 
rien plus simple pour s'y retrouver déjà.




On pourrait quasiment virer l’aide mais ne conserver qu’un lien vers
les raccourcis. (Actuellement, à côté de «Texte», on a une aide
contextuelle qui dit «Le texte de l’article […] comme son nom
l’indique». Et la plupart des entrées sont à l’avenant. Sauf… la
page des raccourcis typographiques donc…

Ou alors faire comme pour Saisies et sa page d'explication accessible 
via un menu.


Mouais : y a déjà un lien "aide" dans le bandeau. Et ça irait dans quel 
menu ? (en statut rédacteur)


Là on aurait juste une page qui rappelle les raccourcis et qui serait 
accessible par le ?.


Alors… je me demandais si le bouton [?] n'était présent qu'en tant 
qu'icone du porte plume (et plus ailleurs), si ça serait suffisant ?


On pourrait même imaginer que certains plugins qui ajoutent des 
raccourcis puissent s'y insérer pour lister les leurs.


Certes. Enfin encore une fois il faut gérer les traductions également.
Ça peut être dans les fichiers de langue des plugins aussi.
Et si tu veux lier des images ou montrer le résultat du code, c'est plus 
difficile je suppose en chaine de langue.


MM.
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-30 Par sujet jeanmarie

Salut,

ça y est, on part un peu tôt du bureau est on sait plus où répondre dans 
le fil de discussion le lendemain matin :D


Du coup, je réponds ici :

*Ok pour la liste des plugins supprimés.*

Y compris *Squelettes**par rubriques* qui induit des pratiques pas 
forcément idéales (je m'inclus dedans) et couteuse en perf (je fais 
confiance au dev sur ce point).


Il est avantageusement remplaçable par Compositions et, pour combler le 
besoin légitime d'Arno de pouvoir verrouiller par composition 
(aujourd'hui, c'est tout ou rien), ça serait une fonctionnalité à 
ajouter dedans. Pour le reste, l'intérêt de la suppression me parait 
l’emporter sur le garder en plugins-dist.


*Compagnon*

Sur le principe, je me dis que c'est utile et accueillant (tendre comme 
SPIP, quoi :) ).
Sur l'utilisation au quotidien, je trouve ça chiant (en tant que 
personne qui utilise intensément l'espace privé) de l'avoir dans les 
pattes tout le temps et devoir le fermer au cas par cas.


Comme évoqué par d'autres dans la discussion, ajouter la possibilité de 
le désactiver pour soi et, tant qu'à y être, pour tout le monde si ça 
mange pas de pain serait super.


Aussi, rendre les boutons qui ferment les boites d'infos (Merci / J’ai 
compris ! / Parfait...) pourraient être plus explicites (avec une croix 
pour ? des styles plus boutons ? ...) pour que les gens les ferment (la 
plupart de mes utilisateur·rices reste avec pendant des mois avant que 
je leur dise qu'ils sont désactivables. > ça mérite un ticket ça ?


Et pour finir, *merci à toutes les personnes qui ont contribué à ces 
grandes avancées *ces derniers temps, c'est vraiment une super dynamique 
pour la communauté !


                jeanmarie

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-30 Par sujet team spipfactoy

*Bonjour,*

Mes deux sous d'un simple rapporteur d'utilisateur.


Lorsque j'install spip + les 26 plugins du core (je cite la doc) pour un 
nouveau


A mon humble avis, il doit embarquer seulement ce qui est nécessaire à 
son fonctionnement minimum (cela permettra au dev , une maintenance plus 
aisé, ils on déjà assez de boulot comme ça).


Aux webmestre de rajouter ce dont il a besoin comme pour les plugins  
des contributeurs


et donc un repertoire plugin-dist , mais que dit la doc ?

Le répertoire |plugins-dist| permet de définir les plugins installés, 
actifs et non désactivables, dès l’installation de SPIP. Il suffit de 
placer les plugins souhaités dans ce répertoire.


Dans la distribution de SPIP, des plugins sont présents par défaut.


et ç'est complété par


  * « Compresseur », pour compresser les Javascript, CSS et HTML,
  * « Filtres images et couleurs », donnant accès aux traitements
graphiques et typographiques,
  * « Porte Plume », fournissant une barre d’outils d’édition des
raccourcis SPIP,
  * « SafeHTML », pour nettoyer les forums et les flux de syndication
d’éléments indésirables.


puis

Il y en a d’autres. On en trouvera la liste complète et à jour sur 
l’autodoc du source 
.


Donc moins il y a de plugins embarqué plus la maintenance est facile 
(m'enfin je l'espére)


*par contre pour l'aide je verrais bien deux boutons dans la barre de 
menu simplement qui redirige vers la futur aide tourné rédacteur et 
l'autre sur les raccourcis *


d’ailleurs il existe  un truc 
(https://contrib.spip.net/Manuel-de-redaction-du-site)



on aurais une entré sur l'aide via la boussole egalement un peu comme

 *


   SPIP.net 

   La documentation officielle et téléchargement de SPIP

   En savoir plus 
 *


   Programmer SPIP-La documentation pour développer avec (...)
   Programmer SPIP 

   La documentation pour développer avec SPIP

   En savoir plus 
 *


   SPIP Code-La documentation du code de SPIP SPIP Code
   

   La documentation du code de SPIP


*donc go go go pour alléger au maximum.*


Après il y avais un truc par ici ou ça discuter deja

https://contrib.spip.net/plugins-dist-indispensables-ou-non



--
spipfactory.fr

En répondant a ce courriel vous acceptez implicitement la diffusion, l’échange 
de la conversation, sauf avis contraire clairement exprimé.

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-30 Par sujet Christian Marget
Bonjour,

Mon avis de modeste utilisateur non dev (ou si peu).

Le 29/04/2021 à 17:31, jacq...@jack31.org a écrit :
> J'ai un doute sur le retrait de ces deux plugins d'aide :
> - Perso le compagnon m'agace et s'il y avait un bouton pour le 
> désactiver entièrement par auteur j'aimerais bien... Le supprimer 
> entièrement ? Est-ce que ça ne donne pas tout de même une (petite) aide 
> aux gens qui découvrent SPIP ?

Entièrement d'accord. C'est un gadget très utile aux débutant(e)s mais
sans intérêt pour quelqu'un qui utilise régulièrement SPIP. Que
chacun(e) puisse le désactiver pour soi me paraît le meilleur compromis.

> - Aide : livrer SPIP sans aide pour les rédacteurs c'est un peu dommage. 
> Mais c'est vrai qu'aujourd'hui c'est plutôt obsolète, il y a peu de 
> choses utilisables. Est-ce que ce serait imaginable que le plugin aille 
> chercher une aide uniquement rédacteur basée sur des articles de 
> spip.net qu'on identifierait par exemple avec un mot clé SPIP_4.0 ? ou 
> une sélection d'articles listée quelque part ? L'idée serait d'en faire 
> une aide vraiment utile avec les "trucs et astuces" utiles au rédacteur

Piste intéressante. Quant à moi, je suis de ceux qui utilisent l'aide
des raccourcis typo chaque fois qu'il faut insérer un truc pas courant.
Celle-là est à conserver.

CM
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-30 Par sujet Pascal JPM
+1
Je me retrouve parfaitement dans ce commentaire.

Pascal


-Message d'origine-
De : Arnaud Martin  
Envoyé : jeudi 29 avril 2021 21:27
À : nicod_ 
Cc : spip-dev@rezo.net; Manu 
Objet : Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par 
défaut




Perso j’utilise les deux méthodes en même temps, sur quasiment tous mes sites.

- rubrique-xx.html… me permet de complètement bloquer la structure au niveau du 
code; et notamment: ça ne fait pas apparaître ce choix de maquette dans 
compositions;
- inc-case-rubrique-xx.html… c’est-à-dire des  de squelettes qui 
exploitent ce système (si on peut le faire avec Compositions, tant mieux, mais 
moi je ne sais pas trop);
- et compositions quand je veux laisser le choix d’utiliser tel ou tel format 
depuis l’espace privé.

La grosse limite de tout faire avec Compositions, pour moi, c’est que ça va 
forcément laisser le choix d’utiliser un squelette qui n’a pas été prévu pour 
être généralisé à l’ensemble du site. 


Sinon, je trouve que rubrique-xx.html c’est ultra pratique pour un webmestre 
amateur. Ça fait partie de ces méthodes que SPIP permet, qui sont 
super-fastoches, et qui en font un outil réellement accessible aux 
bidouilleurs. Je ne dis pas qu’il ne faut pas le désactiver, mais en même temps 
il y a un effet d’affichage à désactiver d’office ce qui facilite la vie des 
webmestres amateurs, alors que le webmestre pro, à la rigueur, il peut bien 
désactiver ce qu’il veut. J’aurais tendance à penser un peu la même chose pour 
Aide et Compagnon: ça fait partie des caractéristiques sympas à mettre en avant 
pour rassurer les débutants. C’est un peu aussi une signature de SPIP.

Perso évidemment je ne les utilise pas. Mais j’installe des sites qui vont être 
utilisés par des débutants. Du coup, si on désactive par défaut, je ne vais pas 
les voir, ces usagers ne vont pas les voir, et je ne vais pas y penser. Par 
contre quand ils sont activés par défaut, quand je fais la formation et… oh 
surprise… regardez il y a des petits outils conçus pour vous débloquer! Ça vaut 
ce que ça vaut, et même s’ils ne sont finalement pas trop utilisés, le simple 
fait de savoir qu’ils ont une aide et un accompagnement intégrés, ça rassure 
les débutants de l’espace privé.

A*



> Le 29 avr. 2021 à 21:04, nicod_  a écrit :
> 
> Le 29/04/2021 à 20:06, Manu a écrit :
>> Oui, n'empêche que les squelettes articles=xx.html ou articles-xx.html, on 
>> peut dire ce qu'on veut, ça rend bien souvent service.
>> Et quand c'est natif, ...c'est simple à mettre en œuvre (!!!) et pour des 
>> débutants, c'est une technique vraiment accessible.
> 
> J'avoue que c'est le seul sur lequel j'ai un doute...
> Il risque de péter des vieux squelettes, et comme tu dis c'est une technique 
> utile.
> Mais bon, y'a déjà des choses qui cassent, et le plugin compositions est 
> quand même vraiment fait pour ça.
> Ce sera précisé dans les notes de mises à jour.
> 
> -- 
> nicod_
> ___
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-30 Par sujet RealET

Eric Lupinacci a écrit le 30/04/2021 à 08:59 :

On pourrait même imaginer que certains plugins qui ajoutent des 
raccourcis puissent s'y insérer pour lister les leurs.


Ça, c'est une super idée !
Merci ;-)


--
RealET


___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-30 Par sujet Pascal JPM
+1
Et je n'ai jamais vu de ralentissement (même sur de gros sites) avec cette 
méthode "historique"... et c'est effectivement bien plus "accessible" pour un 
débutant.
Alors que l'inverse n'est pas vrai (ni rapide, ni facile) !

Cordialement,
Pascal



-Message d'origine-
De : Manu  
Envoyé : jeudi 29 avril 2021 20:06
À : spip-dev@rezo.net
Objet : Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par 
défaut

Le 29/04/2021 à 19:40, nicod_ a écrit :
> Le 29/04/2021 à 17:07, Matthieu Marcillaud a écrit :
>> Nous sommes quelques un·es à proposer qu'on retire des plugins-dist 
>> certains plugins (*ils seront toujours disponibles via la gestion des
>> plugins* pour les réactiver — ça ne veut pas dire qu'ils ne seront 
>> plus maintenus par la communauté)
>
> +1 pour sortir tous les plugins cités, ils seront toujours
> ré-installables pour les nostalgiques :
Oui, n'empêche que les squelettes articles=xx.html ou articles-xx.html, on peut 
dire ce qu'on veut, ça rend bien souvent service.
Et quand c'est natif, ...c'est simple à mettre en œuvre (!!!) et pour des 
débutants, c'est une technique vraiment accessible.
M'enfin, bon, mon brave monsieur, tout change, faut vivre avec son temps !

De toute façon, 10 000 mercis pour tout ce que vous faites et ce superbe SPIP 
;-))

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-30 Par sujet Eric Lupinacci
Le ven. 30 avr. 2021 à 08:50, Arnaud Martin  a
écrit :

>
> Concernant l’aide, en fait il y a *une* seule page qui est franchement
> utile: la page des «raccourcis typographiques». Parce que même après 20 ans
> à faire du SPIP quotidiennement, je connais pas les fusions de cases des
> tableaux, ni les appels de notes de bas de page.
>
> On pourrait quasiment virer l’aide mais ne conserver qu’un lien vers les
> raccourcis. (Actuellement, à côté de «Texte», on a une aide contextuelle
> qui dit «Le texte de l’article […] comme son nom l’indique». Et la plupart
> des entrées sont à l’avenant. Sauf… la page des raccourcis typographiques
> donc…


Ou alors faire comme pour Saisies et sa page d'explication accessible via
un menu.
Là on aurait juste une page qui rappelle les raccourcis et qui serait
accessible par le ?.
On pourrait même imaginer que certains plugins qui ajoutent des raccourcis
puissent s'y insérer pour lister les leurs.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-30 Par sujet chanka...@choc0.net

coucou,

Le 29/04/2021 à 18:16, Maïeul Rouquette a écrit :
a. Pour l'aide, je ne sais pas, je ne l'utilise pas, mais si j'ai bien 
compris le problème principal se situe dans la manière de maintenir 
cette aide ? 
on aurait peut-être pu avoir des versions du plugin Aide successives qui 
aurait été cohérentes avec les versions de SPIP... et là on peut 
peut-être faire une aide qui serait limitée à l'aide aux rédacteurs.
Mais sinon, en dehors de la rédaction, spip.net n'est pas déjà une 
documentation ?



--

chan

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-30 Par sujet RealET

erational a écrit le 30/04/2021 à 08:32 :


Afficher l'aide ne sert plus à rien.
Plus personne ne lit le mode d'emploi avant d'utiliser un système.


Si moi !
Mais seulement cette page : https://www.spip.net/aide/?aide=raccourcis
Pour les ancres
Et les notes de bas de page "non automatiques"

--
RealET


___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-30 Par sujet Arnaud Martin

Concernant l’aide, en fait il y a *une* seule page qui est franchement utile: 
la page des «raccourcis typographiques». Parce que même après 20 ans à faire du 
SPIP quotidiennement, je connais pas les fusions de cases des tableaux, ni les 
appels de notes de bas de page. 

On pourrait quasiment virer l’aide mais ne conserver qu’un lien vers les 
raccourcis. (Actuellement, à côté de «Texte», on a une aide contextuelle qui 
dit «Le texte de l’article […] comme son nom l’indique». Et la plupart des 
entrées sont à l’avenant. Sauf… la page des raccourcis typographiques donc… 


ARNO*
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-30 Par sujet Manu



Après on n'échappera jamais à la question de pourquoi l'un et pas 
l'autre mais faut faire des choix.

Et c'est le moment pour en faire.

go, go, go, les choix qui seront faits seront les bons.

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-30 Par sujet chanka...@choc0.net

hello

Le 29/04/2021 à 18:38, RealET a écrit :
compagnon offre des infos aux nouveaux visiteurs. Il était fait pour 
avoir un accueil plus agréable lors des premières installations.


Est-ce que le rendre inactif pour les webmestres ne serait pas une 
solution simple de ne plus le voir pour "nous", mais qu'il soit encore 
disponible pour les autres ? 
je pense pas du tout que ça convienne à un débutant qui s'installe son 
premier site SPIP : il est bien webmaster, et il a bien pourtant besoin 
du compagnon...


--

chan

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-30 Par sujet erational



Le 29/04/2021 à 17:55, Matthieu Marcillaud a écrit :

Le 29/04/2021 à 17:31, jacq...@jack31.org a écrit :

Le 29/04/2021 à 17:07, Matthieu Marcillaud a écrit :

À débattre
==



Bonjour,
J'ai un doute sur le retrait de ces deux plugins d'aide :
- Perso le compagnon m'agace et s'il y avait un bouton pour le 
désactiver entièrement par auteur j'aimerais bien...


C'est une piste à étudier pour Compagnon, probablement pas trop 
complexe à mettre en place. Mais faut trouver l'UI qui va avec.


[...]

- Aide : livrer SPIP sans aide pour les rédacteurs c'est un peu 
dommage. Mais c'est vrai qu'aujourd'hui c'est plutôt obsolète, il y a 
peu de choses utilisables. Est-ce que ce serait imaginable que le 
plugin aille chercher une aide uniquement rédacteur basée sur des 
articles de spip.net qu'on identifierait par exemple avec un mot clé 
SPIP_4.0 ? ou une sélection d'articles listée quelque part ? L'idée 
serait d'en faire une aide vraiment utile avec les "trucs et astuces" 
utiles au rédacteur


Alors… Je n'ai aucune idée de comment ça pourrait se faire (sans 
douleur, énergie, temps disponible). Mais jusqu'à présent tout le 
monde a renoncé parce que c'était trop compliqué (conserver l'aide 
pour les anciens SPIP, les traductions, faire des aides adaptées à la 
version...) Tellement que bah… ça a fait statut quo — on touche rien, 
on attend la providence.


Pour ma part, si le lien "Aide" du bandeau amenait par exemple à un 
site externe, ça pourrait peut être convenir : et ça permettrait 
d'enlever tous (ou partie) des [?] assez disgracieux (en tout cas sur 
la page article, il y en a beaucoup trop je pense)


Mais même pour un site externe (tel que rediger.spip.net par exemple) 
bah il faut du temps, de l'énergie, de la volonté pour mettre ça en 
place.


Tout n'est pas mauvais dedans pourtant : certaines choses n'ont pas 
changé (l'aide sur la date de publication par exemple). Mais pour 
d'autres éléments (je parle même pas des captures d'écran) on trouve : 
«la page de « Configuration précise » ... choix interface simplifiée / 
interface complète, ... » ou encore le «cookie de correspondance» 
(enlevé aussi)... C'est assez trompeur quoi.



Hello

Je suis tout à fait d'accord avec Marcimat.

Afficher l'aide ne sert plus à rien.
Plus personne ne lit le mode d'emploi avant d'utiliser un système.

Les téléphones portables n'ont même plus de mode d'emploi.

Si on regarde les autres systèmes comme wordpress, il n'y a d'aide 
embarquée non plus

Juste un renvoi sur un site de support
https://fr.wordpress.org/support/


Cela pourrait être l'objet d'une session d'été de batir un site de 
documentetion orienté utilisateur / rédacteur.


bonne journée à tout-e-s




--
_
https://www.erational.org

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-30 Par sujet Eric Lupinacci
Yop,


Le jeu. 29 avr. 2021 à 23:02, Manu  a écrit :

>
> C'est pas faux, mais, en se faisant un peu l'avocat du diable, on peut
> aussi s'interroger sur l'intérêt de supprimer quelque chose dont on
> reconnait une utilité simple et accessible (et largement utilisée ???)et
> que beaucoup vont réactiver assez vite, pourquoi ne pas le laisser ?
>
>
Pour moi il y a quand même une bonne raison : la maintenance.
Je pense que pour cette raison et donc pour les releases successives
mieux vaut se concentrer sur une liste plus limitée de plugins.

Après on n'échappera jamais à la question de pourquoi l'un et pas l'autre
mais faut faire des choix.
Et c'est le moment pour en faire.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-29 Par sujet Manu

Le 29/04/2021 à 21:17, Eric Lupinacci a écrit :

Re,


Le jeu. 29 avr. 2021 à 21:07, Maïeul Rouquette > a écrit :


Le 29.04.21 à 21:04, nicod_ a écrit :
> J'avoue que c'est le seul sur lequel j'ai un doute...
> Il risque de péter des vieux squelettes, et comme tu dis c'est une
> technique utile.
> Mais bon, y'a déjà des choses qui cassent, et le plugin
compositions est
> quand même vraiment fait pour ça.
> Ce sera précisé dans les notes de mises à jour.
>
j'ai tendance à dire que oui c'est pratique pour du dev rapide...
mais
ca coince vite les gens sur des choses pas idéales.


Non mais de toute façon rien ne sera cassé.
Il faut juste installer le plugin hors plugin-dist.
Il n'y a donc aucune régression et tout le monde peut continuer à 
utiliser le plugin.


Le seul truc qui peut se passer c'est si quelqu'un ne lit pas 
l'annonce il aura une surprise temporaire sur son site.
Mais ça ne durera pas et de toute façon rien n'est rédhibitoire car 
c'est juste de l'affichage.
C'est pas faux, mais, en se faisant un peu l'avocat du diable, on peut 
aussi s'interroger sur l'intérêt de supprimer quelque chose dont on 
reconnait une utilité simple et accessible (et largement utilisée ???)et 
que beaucoup vont réactiver assez vite, pourquoi ne pas le laisser ?


Mais, bon, ça peut être un débat sans fin. Pour ma part, la décision qui 
sera prise sera la bonne.



___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-29 Par sujet Arnaud Martin



Perso j’utilise les deux méthodes en même temps, sur quasiment tous mes sites.

- rubrique-xx.html… me permet de complètement bloquer la structure au niveau du 
code; et notamment: ça ne fait pas apparaître ce choix de maquette dans 
compositions;
- inc-case-rubrique-xx.html… c’est-à-dire des  de squelettes qui 
exploitent ce système (si on peut le faire avec Compositions, tant mieux, mais 
moi je ne sais pas trop);
- et compositions quand je veux laisser le choix d’utiliser tel ou tel format 
depuis l’espace privé.

La grosse limite de tout faire avec Compositions, pour moi, c’est que ça va 
forcément laisser le choix d’utiliser un squelette qui n’a pas été prévu pour 
être généralisé à l’ensemble du site. 


Sinon, je trouve que rubrique-xx.html c’est ultra pratique pour un webmestre 
amateur. Ça fait partie de ces méthodes que SPIP permet, qui sont 
super-fastoches, et qui en font un outil réellement accessible aux 
bidouilleurs. Je ne dis pas qu’il ne faut pas le désactiver, mais en même temps 
il y a un effet d’affichage à désactiver d’office ce qui facilite la vie des 
webmestres amateurs, alors que le webmestre pro, à la rigueur, il peut bien 
désactiver ce qu’il veut. J’aurais tendance à penser un peu la même chose pour 
Aide et Compagnon: ça fait partie des caractéristiques sympas à mettre en avant 
pour rassurer les débutants. C’est un peu aussi une signature de SPIP.

Perso évidemment je ne les utilise pas. Mais j’installe des sites qui vont être 
utilisés par des débutants. Du coup, si on désactive par défaut, je ne vais pas 
les voir, ces usagers ne vont pas les voir, et je ne vais pas y penser. Par 
contre quand ils sont activés par défaut, quand je fais la formation et… oh 
surprise… regardez il y a des petits outils conçus pour vous débloquer! Ça vaut 
ce que ça vaut, et même s’ils ne sont finalement pas trop utilisés, le simple 
fait de savoir qu’ils ont une aide et un accompagnement intégrés, ça rassure 
les débutants de l’espace privé.

A*



> Le 29 avr. 2021 à 21:04, nicod_  a écrit :
> 
> Le 29/04/2021 à 20:06, Manu a écrit :
>> Oui, n'empêche que les squelettes articles=xx.html ou articles-xx.html, on 
>> peut dire ce qu'on veut, ça rend bien souvent service.
>> Et quand c'est natif, ...c'est simple à mettre en œuvre (!!!) et pour des 
>> débutants, c'est une technique vraiment accessible.
> 
> J'avoue que c'est le seul sur lequel j'ai un doute...
> Il risque de péter des vieux squelettes, et comme tu dis c'est une technique 
> utile.
> Mais bon, y'a déjà des choses qui cassent, et le plugin compositions est 
> quand même vraiment fait pour ça.
> Ce sera précisé dans les notes de mises à jour.
> 
> -- 
> nicod_
> ___
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-29 Par sujet Eric Lupinacci
Re,


Le jeu. 29 avr. 2021 à 21:07, Maïeul Rouquette  a écrit :

> Le 29.04.21 à 21:04, nicod_ a écrit :
> > J'avoue que c'est le seul sur lequel j'ai un doute...
> > Il risque de péter des vieux squelettes, et comme tu dis c'est une
> > technique utile.
> > Mais bon, y'a déjà des choses qui cassent, et le plugin compositions est
> > quand même vraiment fait pour ça.
> > Ce sera précisé dans les notes de mises à jour.
> >
> j'ai tendance à dire que oui c'est pratique pour du dev rapide... mais
> ca coince vite les gens sur des choses pas idéales.
>
>
Non mais de toute façon rien ne sera cassé.
Il faut juste installer le plugin hors plugin-dist.
Il n'y a donc aucune régression et tout le monde peut continuer à utiliser
le plugin.

Le seul truc qui peut se passer c'est si quelqu'un ne lit pas l'annonce il
aura une surprise temporaire sur son site.
Mais ça ne durera pas et de toute façon rien n'est rédhibitoire car c'est
juste de l'affichage.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-29 Par sujet Maïeul Rouquette

Le 29.04.21 à 21:04, nicod_ a écrit :

Le 29/04/2021 à 20:06, Manu a écrit :
Oui, n'empêche que les squelettes articles=xx.html ou 
articles-xx.html, on peut dire ce qu'on veut, ça rend bien souvent 
service.
Et quand c'est natif, ...c'est simple à mettre en œuvre (!!!) et pour 
des débutants, c'est une technique vraiment accessible.


J'avoue que c'est le seul sur lequel j'ai un doute...
Il risque de péter des vieux squelettes, et comme tu dis c'est une 
technique utile.
Mais bon, y'a déjà des choses qui cassent, et le plugin compositions est 
quand même vraiment fait pour ça.

Ce sera précisé dans les notes de mises à jour.

j'ai tendance à dire que oui c'est pratique pour du dev rapide... mais 
ca coince vite les gens sur des choses pas idéales.


je connais des associations qui aimeraient rendre generique leur 
squelettes mais qui sont coinciés pour avoir pris ce biais d'écrire en 
dur un numéro de rubrique...


___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-29 Par sujet nicod_

Le 29/04/2021 à 20:06, Manu a écrit :
Oui, n'empêche que les squelettes articles=xx.html ou articles-xx.html, 
on peut dire ce qu'on veut, ça rend bien souvent service.
Et quand c'est natif, ...c'est simple à mettre en œuvre (!!!) et pour 
des débutants, c'est une technique vraiment accessible.


J'avoue que c'est le seul sur lequel j'ai un doute...
Il risque de péter des vieux squelettes, et comme tu dis c'est une 
technique utile.
Mais bon, y'a déjà des choses qui cassent, et le plugin compositions est 
quand même vraiment fait pour ça.

Ce sera précisé dans les notes de mises à jour.

--
nicod_
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-29 Par sujet Manu

Le 29/04/2021 à 19:40, nicod_ a écrit :

Le 29/04/2021 à 17:07, Matthieu Marcillaud a écrit :
Nous sommes quelques un·es à proposer qu'on retire des plugins-dist 
certains plugins (*ils seront toujours disponibles via la gestion des 
plugins* pour les réactiver — ça ne veut pas dire qu'ils ne seront 
plus maintenus par la communauté)


+1 pour sortir tous les plugins cités, ils seront toujours 
ré-installables pour les nostalgiques :
Oui, n'empêche que les squelettes articles=xx.html ou articles-xx.html, 
on peut dire ce qu'on veut, ça rend bien souvent service.
Et quand c'est natif, ...c'est simple à mettre en œuvre (!!!) et pour 
des débutants, c'est une technique vraiment accessible.

M'enfin, bon, mon brave monsieur, tout change, faut vivre avec son temps !

De toute façon, 10 000 mercis pour tout ce que vous faites et ce superbe 
SPIP ;-))


___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-29 Par sujet nicod_

Le 29/04/2021 à 17:07, Matthieu Marcillaud a écrit :
Nous sommes quelques un·es à proposer qu'on retire des plugins-dist 
certains plugins (*ils seront toujours disponibles via la gestion des 
plugins* pour les réactiver — ça ne veut pas dire qu'ils ne seront plus 
maintenus par la communauté)


+1 pour sortir tous les plugins cités, ils seront toujours 
ré-installables pour les nostalgiques :)


--
nicod_
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-29 Par sujet RealET

Matthieu Marcillaud a écrit le 29/04/2021 à 17:07 :

Bonjour,


Re bonjour,


Squelettes par rubriques


Ça permet de faire des squelettes tel que "article=3.html". Gourmands en 
performance pour retrouver ces squelettes, on préfère utiliser 
maintenant d'autres méthodes, notamment avec le plugin Compositions.


Ça pourrait être utile d'avoir une page utilitaire qui scannerait les 
racines du path pour voir si des fichiers correspondent à cette 
utilisation pour le signaler ?


Idem pour scanner les squelettes à la recherche de (BREVES) et autres ?


--
RealET


___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-29 Par sujet RealET

Matthieu Marcillaud a écrit le 29/04/2021 à 17:07 :

Bonjour,


Bonjour

+1 sur tout sauf :


Compagnon ?
-

Là c'est plus subjectif et plus fortement sujet à discussion. 
Le 
compagnon offre des infos aux nouveaux visiteurs. Il était fait pour 
avoir un accueil plus agréable lors des premières installations.


Est-ce que le rendre inactif pour les webmestres ne serait pas une 
solution simple de ne plus le voir pour "nous", mais qu'il soit encore 
disponible pour les autres ?





Aide ?


Là encore plutôt sujet à discussion. Ce plugin ajoute les icones [?] à 
différents endroits de l'espace privé. Mais cette aide n'est plus à jour 
et est la même pour toutes les versions de SPIP. Quand elle n'est pas 
obsolète.


1) Il faut la garder pour le côté rassurant
2) quand j'ai besoin de la syntaxe pour les ancres ou pour les notes de 
bas de page utilisées plusieurs fois ou nommées (genre explicitement * 
au lieu d'un numéro), j'utilise l'aide de SPIP



--
RealET


___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-29 Par sujet jacques

Le 29/04/2021 à 17:55, Matthieu Marcillaud a écrit :
Pour ma part, si le lien "Aide" du bandeau amenait par exemple à un 
site externe, ça pourrait peut être convenir : et ça permettrait 
d'enlever tous (ou partie) des [?] assez disgracieux (en tout cas sur 
la page article, il y en a beaucoup trop je pense)

OK, ce serait sans doute le plus simple à mettre en place


Mais même pour un site externe (tel que rediger.spip.net par exemple) 
bah il faut du temps, de l'énergie, de la volonté pour mettre ça en 
place.
Est-ce qu'il ne serait pas possible de faire ça à l'économie, en ciblant 
uniquement aide rédacteur. Il existe déjà beaucoup de choses. Serait-il 
possible d'alimenter une nouvelle rubrique sur spip.net en se servant 
d'un plugin comme polyhierarchie ? Du coup on mettrait dans cette 
nouvelle rubrique tous les articles qui touchent la rédaction en 4.0.


Tout n'est pas mauvais dedans pourtant : certaines choses n'ont pas 
changé (l'aide sur la date de publication par exemple). Mais pour 
d'autres éléments (je parle même pas des captures d'écran) on trouve : 
«la page de « Configuration précise » ... choix interface simplifiée / 
interface complète, ... » ou encore le «cookie de correspondance» 
(enlevé aussi)... C'est assez trompeur quoi.
Il ne resterait "plus qu'à" faire le tri des patates, reprendre les 
articles où des choses obsolètes sont mélangées...


Jacques
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-29 Par sujet tcharlss



Le 29/04/2021 à 18:16, Maïeul Rouquette a écrit :


Pour faire cours
- oui pour ceux "pas d'objections", mais il faudra faire un gros 
travaille sur la doc

- à debattre


Pareil pour moi.
En insistant sur le fait de bien communiquer sur ces retraits.
Notamment « squelettes par rubrique », sur lequel pas mal de vieux 
squelettes doivent se reposer (mais en soi ça semble préférable de plus 
en faire une solution officielle/recommandée en le distribuant par défaut).


___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-29 Par sujet JLuc

Un peu pareil : Ok pour tout supprimer mais garder le compagnon et l'aide
qui, tout insuffisants voire imparfaits qu'ils sont,
sont tout de même une utile ligne guide pour qui débarque.

Ou si ce n'est pas l'aide actuelle, un équivalent modernisé...
sous la forme d'un compagnon multiplié, escamotable mais persistant ?

JL

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-29 Par sujet Maïeul Rouquette

Le 29.04.21 à 17:07, Matthieu Marcillaud a écrit :

Bonjour,

Nous sommes donc partis pour versionner SPIP 4.0 à la place de SPIP 3.3 
la prochaine version.


Nous sommes quelques un·es à proposer qu'on retire des plugins-dist 
certains plugins (*ils seront toujours disponibles via la gestion des 
plugins* pour les réactiver — ça ne veut pas dire qu'ils ne seront plus 
maintenus par la communauté)




Pour faire cours
- oui pour ceux "pas d'objections", mais il faudra faire un gros 
travaille sur la doc

- à debattre

a. Pour l'aide, je ne sais pas, je ne l'utilise pas, mais si j'ai bien 
compris le problème principal se situe dans la manière de maintenir 
cette aide ?
b. Pour le compagnon, je dirais à garder, mais est-ce qu'on ne pourrait 
pas avoir quelque chose qui detecte la première connexion à l'espace 
privé, et nous demande "Connaissez vous spip" > si oui desactive le 
compagnon

C. pour les wheels suite aux remarques d'Eric
a. OK pour passage en JSON avec les ajustements de cy_altern
	b. Reflechissions à plus long terme sur la syntaxe et les outils, mais 
le but c'est de sortir une 4.0, pas de refaire SPIP (par exemple 
Markdown, oui pq pas, mais il a aussi des limite !)
	c. Surtout si on sort les wheels maintenant, j'ai peur de choses qu'on 
aurait pas pensé qui existe que dans les wheels mais pas dans le core de 
SPIP

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-29 Par sujet RastaPopoulos
Le 29/04/2021 à 17:55, Matthieu Marcillaud a écrit :
> Tout n'est pas mauvais dedans pourtant : certaines choses n'ont pas changé 
> (l'aide sur la date de publication par exemple). Mais pour d'autres éléments 
> (je parle même pas des captures d'écran) on trouve : «la page de « 
> Configuration précise » ... choix interface simplifiée / interface complète, 
> ... » ou encore le «cookie de correspondance» (enlevé aussi)... C'est assez 
> trompeur quoi.

Je crois qu'on est à peu près tou⋅tes d'accord pour dire que dans l'absolu, 
avoir de l'aide c'est bien *mais* que énormément de choses sont obsolètes (en 
contenu et en affichage, capture).

La question est donc : est-ce qu'il ne vaut pas mieux aucune aide, qu'une aide 
obsolète ?

Pour l'instant j'ai plutôt tendance à penser que c'est mieux sans.

Et peut-être qu'aucune aide visible pendant un moment nous poussera mieux à 
nous saisir du sujet, possiblement en imaginant ensemble un nouveau système 
plus pérenne, en prenant le temps de le concevoir de 0. Sans essayer de réparer 
le système actuel qui ne va pas du tout (le fait d'avoir la même aide quelque 
soit la version notamment).

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-29 Par sujet Eric Lupinacci
Hello,


Le jeu. 29 avr. 2021 à 17:56, RastaPopoulos  a
écrit :

> Le 29/04/2021 à 17:44, Eric Lupinacci a écrit :
> > Maintenant, franchement je ne vois pas pourquoi le JSON poserait des
> problèmes à partir du moment où obtient les mêmes tableaux de wheels en
> décodant le YAML ou le JSON.
>
> Pour l'instant, un des arguments répondu, était que les wheels font
> parfois de nombreuses choses compliquées, dans un ordre précis, et que le
> YAML permet de faire des commentaires entre chaque morceau, ce qui n'est
> pas le cas du JSON.
>
> https://git.spip.net/spip/textwheel/src/branch/master/wheels/spip/spip-listes.yaml#L31
>
> Après les wheels… c'est un système qui me parait obsolète de nos jours, où
> il y a des vrais parseurs de grammaire désormais performants (avec PHP 7,
> PHP 8), et on devrait utiliser ça dans le futur plutôt que des regexs.
>
> Concrètement les wheels actuelles, donc qui ont des commentaires dans le
> YAML, ces fichiers n'ont pas bougé depuis… 10 ans… 7 ans… suivant les
> fichiers.
> Du coup c'est peut-être pas grave de ne plus avoir ces commentaires. En
> tout cas placés à cet endroit.
>
>
Oui cy_altern a remonté le même sujet.
Après il faut relativiser le nombre de commentaires.
Mais comme le propose cy_altern on peut insérer ces commentaires dans un
index "_commentaires:".
Moi j'avais proposé un readme.

Donc je pense que ça doit pouvoir se gérer facilement.
Après oui c'est obsolète les wheels si on se positionne pour intégrer
markdown mais c'est une première étape de nettoyage.
Je ne suis pas sur qu'on change aussi facilement de langage.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-29 Par sujet YannX SPIP(hot)

Bonjour,

Un retour d'un utilisateur, pour soutenir la tendance : plugin  "Aide" à 
conserver !
 (voire monter un plugin générique :Aide + Manuel + Compagnon + ... 
formule intégrée ?)


Mais peut-etre peut-on aussi intégrer l'accès au document Spip_redacteur 
d'Erational

(d'ailleurs déjà refondu en .ODT et mis-à-jour/en-ligne pour SPIP 3.2 :
https://www.spippourlesnuls.fr/vous-accueillir/guide-du-redacteur-spip-3-2/ 
)
  avec un simple menu d'appel par page en boite_latérale (ou en pop-up 
pour smartphones) ?


Dès que l'interface SPIP 3.3/4.  sera finalisée, j'en ferai la version 
ad'hoc

   ainsi sans doute qu'une extension pour les logos et images,
   mais là j'aurai besoin de relecteurs pour me signaler les oublis & 
inconnus ;-) ;-(


--
YannX
http://www.spippourlesnuls.fr

PS cette interface est une surprise, agréable après un temps d'adaptation.
 mais au jour d'hier il me manquait toujours le style .btn .submit 
sur les "Enregistrer" ?
    Et je suggérerais de prévoir deux declinaisons de style disponibles 
en standard :
    - pour les smartphones  (usage plus généralisé) : faire un 
toggle affichant / masquant les boites latérales
    - pour les écrans larges : systématiser l'option "à la WP" qui 
reporte le menu principal à gauche
 (pour profiter pleinement de la hauteur limitée des écrans 
d'ordis, relativement à la largeur)


Le 29/04/2021 à 17:07, Matthieu Marcillaud a écrit :

Bonjour,

Nous sommes donc partis pour versionner SPIP 4.0 à la place de SPIP 
3.3 la prochaine version.


Nous sommes quelques un·es à proposer qu'on retire des plugins-dist 
certains plugins (*ils seront toujours disponibles via la gestion des 
plugins* pour les réactiver — ça ne veut pas dire qu'ils ne seront 
plus maintenus par la communauté)




Déjà retiré
===

JQuery UI
-

Déjà avant tout soulignons que nous avons déjà enlevé "jquery-ui" des 
plugins-dist car cette librairie javascript n'est plus maintenue, et 
nous avons ajouté les alternatives JS (un "picker" de date et un 
"sortable") dans le core pour les utilisations principales qu'il y avait.


Pour d'autres plugins (Fabrique, Saisies, Albums, Rangs, ...), dans 
une premier temps il suffit d'ajouter un necessite à jquery-ui et de 
le réactiver en plugin. Dans un second temps, la communauté adaptera 
les plugins avec du nouveau code.




Pas d'objection ?
=


Vertèbres
-

Un outil de visualisation des tables SQL de SPIP. Ce plugin n'a 
pratiquement pas bougé depuis sa sortie. Il est avantageusement 
remplaçable par le plugin "Adminer".



Organiseur
--

Il contient l'agenda interne, la possibilité de messages entre auteurs 
et de pense-bête. Très pratique a une époque assez lointaine, un peu 
moins maintenant avec des agendas et outils de discussion sur tous les 
téléphones !


Il n'est a priori quasiment jamais utilisé sur les sites maintenant.

Les plugins comme Agenda ou Manuel du site sont parfois selon le 
besoin aussi une alternative.



Brèves
--

De courts éléments éditoriaux sans auteur.


Squelettes par rubriques


Ça permet de faire des squelettes tel que "article=3.html". Gourmands 
en performance pour retrouver ces squelettes, on préfère utiliser 
maintenant d'autres méthodes, notamment avec le plugin Compositions.



Pétitions
-

Permet de créer des pétitions. On reproche souvent au plugin de 
manquer de champs, de ne pas être adapté à ceci ou cela. Personne n'a 
pris le temps pour l'améliorer récemment.





À débattre
==


Compagnon ?
-

Là c'est plus subjectif et plus fortement sujet à discussion. Le 
compagnon offre des infos aux nouveaux visiteurs. Il était fait pour 
avoir un accueil plus agréable lors des premières installations.



Aide ?


Là encore plutôt sujet à discussion. Ce plugin ajoute les icones [?] à 
différents endroits de l'espace privé. Mais cette aide n'est plus à 
jour et est la même pour toutes les versions de SPIP. Quand elle n'est 
pas obsolète.




Des avis par ici ?

Bien à vous,
MM.

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip



--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-29 Par sujet RastaPopoulos
Le 29/04/2021 à 17:44, Eric Lupinacci a écrit :
> Maintenant, franchement je ne vois pas pourquoi le JSON poserait des 
> problèmes à partir du moment où obtient les mêmes tableaux de wheels en 
> décodant le YAML ou le JSON.

Pour l'instant, un des arguments répondu, était que les wheels font parfois de 
nombreuses choses compliquées, dans un ordre précis, et que le YAML permet de 
faire des commentaires entre chaque morceau, ce qui n'est pas le cas du JSON.
https://git.spip.net/spip/textwheel/src/branch/master/wheels/spip/spip-listes.yaml#L31

Après les wheels… c'est un système qui me parait obsolète de nos jours, où il y 
a des vrais parseurs de grammaire désormais performants (avec PHP 7, PHP 8), et 
on devrait utiliser ça dans le futur plutôt que des regexs.

Concrètement les wheels actuelles, donc qui ont des commentaires dans le YAML, 
ces fichiers n'ont pas bougé depuis… 10 ans… 7 ans… suivant les fichiers.
Du coup c'est peut-être pas grave de ne plus avoir ces commentaires. En tout 
cas placés à cet endroit.

-- 
RastaPopoulos

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-29 Par sujet Matthieu Marcillaud

Le 29/04/2021 à 17:31, jacq...@jack31.org a écrit :

Le 29/04/2021 à 17:07, Matthieu Marcillaud a écrit :

À débattre
==



Bonjour,
J'ai un doute sur le retrait de ces deux plugins d'aide :
- Perso le compagnon m'agace et s'il y avait un bouton pour le 
désactiver entièrement par auteur j'aimerais bien...


C'est une piste à étudier pour Compagnon, probablement pas trop complexe 
à mettre en place. Mais faut trouver l'UI qui va avec.


[...]

- Aide : livrer SPIP sans aide pour les rédacteurs c'est un peu dommage. 
Mais c'est vrai qu'aujourd'hui c'est plutôt obsolète, il y a peu de 
choses utilisables. Est-ce que ce serait imaginable que le plugin aille 
chercher une aide uniquement rédacteur basée sur des articles de 
spip.net qu'on identifierait par exemple avec un mot clé SPIP_4.0 ? ou 
une sélection d'articles listée quelque part ? L'idée serait d'en faire 
une aide vraiment utile avec les "trucs et astuces" utiles au rédacteur


Alors… Je n'ai aucune idée de comment ça pourrait se faire (sans 
douleur, énergie, temps disponible). Mais jusqu'à présent tout le monde 
a renoncé parce que c'était trop compliqué (conserver l'aide pour les 
anciens SPIP, les traductions, faire des aides adaptées à la version...) 
Tellement que bah… ça a fait statut quo — on touche rien, on attend la 
providence.


Pour ma part, si le lien "Aide" du bandeau amenait par exemple à un site 
externe, ça pourrait peut être convenir : et ça permettrait d'enlever 
tous (ou partie) des [?] assez disgracieux (en tout cas sur la page 
article, il y en a beaucoup trop je pense)


Mais même pour un site externe (tel que rediger.spip.net par exemple) 
bah il faut du temps, de l'énergie, de la volonté pour mettre ça en place.


Tout n'est pas mauvais dedans pourtant : certaines choses n'ont pas 
changé (l'aide sur la date de publication par exemple). Mais pour 
d'autres éléments (je parle même pas des captures d'écran) on trouve : 
«la page de « Configuration précise » ... choix interface simplifiée / 
interface complète, ... » ou encore le «cookie de correspondance» 
(enlevé aussi)... C'est assez trompeur quoi.



MM.
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-29 Par sujet Eric Lupinacci
Hello,


Le jeu. 29 avr. 2021 à 17:07, Matthieu Marcillaud  a
écrit :

>
> JQuery UI
> -
>
> Déjà avant tout soulignons que nous avons déjà enlevé "jquery-ui" des
> plugins-dist car cette librairie javascript n'est plus maintenue, et
> nous avons ajouté les alternatives JS (un "picker" de date et un
> "sortable") dans le core pour les utilisations principales qu'il y avait.
>
>
Ah c'est une bonne raison, par contre, ce n'est pas la seule dans ce cas,
j'y reviendrai plus loin.



>
> Vertèbres
> -
>
> Un outil de visualisation des tables SQL de SPIP. Ce plugin n'a
> pratiquement pas bougé depuis sa sortie. Il est avantageusement
> remplaçable par le plugin "Adminer".
>
>
+1


>
> Organiseur
> --
>
> Les plugins comme Agenda ou Manuel du site sont parfois selon le besoin
> aussi une alternative.
>
>
Ou Pense-bêtes. Donc +1


>
> Brèves
> --
>
>
+2


> Squelettes par rubriques
> 
>
> Ça permet de faire des squelettes tel que "article=3.html". Gourmands en
> performance pour retrouver ces squelettes, on préfère utiliser
> maintenant d'autres méthodes, notamment avec le plugin Compositions.
>
>
+1


>
> Pétitions
> -
>

+1, c'est rare d'utilisation donc pas forcément nécessaire en Dist.


> Compagnon ?
> -
>
>
Non je pense qu'il faut le garder.


> Aide ?
> 
>
>
Devrait être indispensable mais est-il vraiment consulté dans l'état.
Néanmoins, psychologiquement je dirais qu'il faudrait le garder.

Et donc pour la fin je reviens sur TextWheel et sa librairie sfyaml ultra
moisie en m'inscrustant dans le fil de Mathieu qui a surement plus de
chance d'être répondu que le mien...
Pourquoi la conserver ainsi ?
Donc deux solutions, on prend la branche JSON que j'ai proposé et qui
assure la compatibilité voire le fallback avec l'existant YAML si on
trouvait des problèmes, soit on ajoute le plugin YAML dans le Core puisque
celui-ci nécessite ce format en le mettant à jour de ses librairies.
Maintenant, franchement je ne vois pas pourquoi le JSON poserait des
problèmes à partir du moment où obtient les mêmes tableaux de wheels en
décodant le YAML ou le JSON.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-29 Par sujet jacques

Le 29/04/2021 à 17:07, Matthieu Marcillaud a écrit :

À débattre
==

Compagnon ?
-

Là c'est plus subjectif et plus fortement sujet à discussion. Le 
compagnon offre des infos aux nouveaux visiteurs. Il était fait pour 
avoir un accueil plus agréable lors des premières installations.


Aide ?


Là encore plutôt sujet à discussion. Ce plugin ajoute les icones [?] à 
différents endroits de l'espace privé. Mais cette aide n'est plus à 
jour et est la même pour toutes les versions de SPIP. Quand elle n'est 
pas obsolète.


Des avis par ici ?

Bonjour,
J'ai un doute sur le retrait de ces deux plugins d'aide :
- Perso le compagnon m'agace et s'il y avait un bouton pour le 
désactiver entièrement par auteur j'aimerais bien... Le supprimer 
entièrement ? Est-ce que ça ne donne pas tout de même une (petite) aide 
aux gens qui découvrent SPIP ?
- Aide : livrer SPIP sans aide pour les rédacteurs c'est un peu dommage. 
Mais c'est vrai qu'aujourd'hui c'est plutôt obsolète, il y a peu de 
choses utilisables. Est-ce que ce serait imaginable que le plugin aille 
chercher une aide uniquement rédacteur basée sur des articles de 
spip.net qu'on identifierait par exemple avec un mot clé SPIP_4.0 ? ou 
une sélection d'articles listée quelque part ? L'idée serait d'en faire 
une aide vraiment utile avec les "trucs et astuces" utiles au rédacteur


Jacques
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


  1   2   >