Bonjour,
J'ai rajouté le traitement des St... et des Bx... dans le plugin.
Du coup, je me suis rendu compte que le plugin fait du sens (<sup>) *et* de la présentation (<small>).
Il me semble qu'il faudrait virer tous les small pour ne garder que les sup.
J'y vais ?
D'autre part, Pat, je ne comprends pas pourquoi tu as ta propre version forkée dans le plugin tweaks sans que tu backporte tes améliorations dans l'original ?
--
RealET
D'autre part, Pat, je ne comprends pas pourquoi tu as ta propre version
forkée dans le plugin tweaks sans que tu backporte tes améliorations
dans l'original ?
A-t-on besoin de deux versions ? Il me semble que ce qui est dans
tweaks pourrait très bien ne plus exister indépendamment de tweaks
(sauf si besoin explicite).
-- Fil
Fil wrote:
A-t-on besoin de deux versions ? Il me semble que ce qui est dans
tweaks pourrait très bien ne plus exister indépendamment de tweaks
(sauf si besoin explicite).
D'accord que juste une version avec, dans l'idéal, une façon facile de choisir les boutons qui sont montrés, serait le mieux.
Ceci dit, c'est bien Jacques qui a fait le gros du travail là-dessus. Je pense donc qu'il a le droit de poser la question dans le sens inverse 
Paolo
il a le droit de poser la question dans le sens inverse
Tout le monde a le droit de poser toutes les questions, Paolo, travail ou pas
Ce que je veux dire, c'est qu'il me semble dommage de conserver un
fork, sauf s'il y a une raison convaincante de le faire. L'idée des
tweaks est séduisante, et dans la mesure où chaque tweak est activable
indépendamment des autres, ça ne me paraît pas poser de problème ;
sauf s'il y a craintes ou critiques précises (sécurité, performance,
interface ?) ; auquel cas les expliciter permettrait d'améliorer
ensemble tout ça -- ce qui est aussi la raison d'être de la Zone
-- Fil
* Paolo tapotait, le 16/04/2007 10:35:
Ceci dit, c'est bien Jacques qui a fait le gros du travail là-dessus.
Ne confonds pas la Barre Typo Enrichie et le plugin Typo Exposants (sur lequel c'est ma première contribution).
--
RealET
RealET wrote:
Ne confonds pas la Barre Typo Enrichie et le plugin Typo Exposants (sur lequel c'est ma première contribution).
Encore une barre ! En effet, je trébuche là-dedans.
merci, Paolo
Fil a écrit :
il a le droit de poser la question dans le sens inverse
Tout le monde a le droit de poser toutes les questions, Paolo, travail ou pasCe que je veux dire, c'est qu'il me semble dommage de conserver un
fork, sauf s'il y a une raison convaincante de le faire. L'idée des
tweaks est séduisante, et dans la mesure où chaque tweak est activable
indépendamment des autres, ça ne me paraît pas poser de problème ;
sauf s'il y a craintes ou critiques précises (sécurité, performance,
interface ?) ; auquel cas les expliciter permettrait d'améliorer
ensemble tout ça -- ce qui est aussi la raison d'être de la Zone
Hello,
L'idée de depart de tweaks, c'est, si j'ai bien compris :
- de faciliter l'installation (je suis moyennement convaincu, mais bon...)
- de ne pas surcharger le path (40 plugins, ca doit commencer à se sentir en perf...)
- de garantir la compatibilité entre differents ajouts fonctionnels (et ca, c'est pas rien !)
Meme si on considere que tweaks est l'emplacement naturel d'une fonctionnalité comme la BTE, je ne vois pas pourquoi celle-ci devrait se fondre dans tweaks et s'encombrer de toutes les contraintes qui vont avec.
Pour pouvoir developper et ameliorer, il faut souvent tout casser.
Se fixer une compatibilité arriere, c'est deja bien, mais si il faut verifier que les developpements des 12 modules autour restent compatibles, plus personne ne bouge !
D'autre part, tu parles de sécurité, perf, ergo... , j'ajouterai fiabilité et longévité.
Quand j'utilise du code, je regarde qui l'a produit, ca me donne une idée de la qualité et de l'activité que je vais rencontrer.
Si j'utilise la BTE, spip-forms ou spip-liste, c'est en partie parce que je sais que les developpements ne vont pas s'arreter demain, et que si je leve un gros bug, j'aurai des gens à qui en parler, avec qui trouver la meilleure solution. Alors tweaks ... je regarderai dans 1 ou 2 ans (c'est pas vrai hein, mais c'est l'idée).
Enfin, pour revenir sur le developpement collaboratif, d'experience, je dirais que le fork est souvent une etape necessaire.
Quand je tatonne sur une fonctionnalité, je ne vais pas aller casser le developpement de quelqu'un.
Je copie, je modifie, ca peut prendre longtemps donc je me retrouve rapidement de fait en situation de fork.
Quand c'est operationnel, je regarde comment réintegrer mes developpements au plugin d'origine, je peux discuter concretement avec l'auteur : lui sait ce qui a bougé depuis et pourquoi, moi je sais quelles modifs ont été faites pour ajouter la fonctionnalité, ce qui m'a compliqué la vie, bref, c'est le plus efficace car c'est un vrai echange, pas une succession de monologues.
Bref, le gros plugin qui concentrerait plein de choses devenant le seul lieu possible de developpement, je ne crois vraiment pas que ca soit une bonne idée.
Attention, je pense que l'idée de départ est bonne : il faut regrouper les fonctionnalités dans un seul et meme plugin, mais j'appelerai ca un plugin d'integration.
Le but doit rester la compatibilité et les perfs, mais il ne faut pas confondre encore une fois developpement et distribution.
C'est le grand probleme de la zone depuis le debut : vouloir etre un outil de developpement, mais se soucier des utilisateurs.
Les utuilisateurs de la zone, ce sont des developpeurs.
Si chaque morceau de tweaks etait un plugin a part, on pourrait avoir plein de version de tweaks, embarquant tel ou tel fonction, libre à l'utilisateur de choisir la plus proche de ses besoins.
On pourrait se concentrer sur la qualité du code et monter des librairies de fonctions plutot que de redevelopper nos petits filtres chacun dans notre coin (et du coup, on serait obligé d'avancer sur un systeme de gestion de dependances)
C'est une idée que je defend d'ailleurs au niveau des plugins eux meme : il faut aller vers des distributions, incluant spip et differents plugins préinstallés, ainsi que les squelettes.
ca, ca faciliterait la vie à l'utilisateur.
L'utilisateur ne cherche pas la derniere version de tel plugin, il cherche une fonctionnalité, je crois qu'on a tendance à l'oublier quand on a le nez dans le code.
Alors ayons le nez dans le code ou occupons nous des utilisateurs, mais pas les deux en meme temps, ca n'apporte rien de bon.
Mes 2 sous.
@++
Meme si on considere que tweaks est l'emplacement naturel d'une
fonctionnalité comme la BTE,
NOOOOON pas de confusion : je ne parle pas de la BTE, mais des "exposants"...
Les tweaks ne sont que des "petites bidouilles" (nom que je préconise
pour ce plugin, d'ailleurs, plutôt que tweak-spip). La plupart de ces
petites bidouilles se limitent à une ou deux lignes, et appellent bien
souvent des trucs non documentés du core... Tandis que la BTE est une
énorme bidouille, qui a donc vocation à rester en plugin autonome.
[...]
Bref, le gros plugin qui concentrerait plein de choses devenant le seul
lieu possible de developpement, je ne crois vraiment pas que ca soit une
bonne idée.
Attention, je pense que l'idée de départ est bonne : il faut regrouper
les fonctionnalités dans un seul et meme plugin, mais j'appelerai ca un
plugin d'integration.
Peut-être faudrait-il découper ce plugin en un conteneur générique de « tweaks » avec une API stable et une gestion de classement par tags, chaque tweak étant ainsi développé indépendamment. Un type particulier de plugin light, en somme.
-Nicolas
--
Nicolas "Brush" HOIZEY
Clever Age : http://www.clever-age.com/
Gastero Prod : http://www.gasteroprod.com/
Photos : http://www.flickr.com/gp/38608514@N00/M1c002
Fil a écrit :
Meme si on considere que tweaks est l'emplacement naturel d'une
fonctionnalité comme la BTE,NOOOOON pas de confusion : je ne parle pas de la BTE, mais des "exposants"...
oups ...
mais ca ne change rien sur le fond.
Distribuer les petites bidouilles dans un plugin c'est bien, mais pourquoi s'obliger un lieu commun pour les developper ?
L'important, c'est d'avoir un plugin ou consolider tout ca, en prenant le temps de verifier la compatibilité, mais je persiste : en phase de developpement, le regroupement est contre-productif.
Un phase d'integration permet d'avoir du code de meilleure qualité et, eventuellement, de reperer des fonctions mutualisables, optimisables, pour les regrouper dans une librairie.
@++
RealET a écrit :
Bonjour,
D'autre part, Pat, je ne comprends pas pourquoi tu as ta propre version forkée dans le plugin tweaks sans que tu backporte tes améliorations dans l'original ?
Salut,
Le Pr-Dr-St et compagnie figurent en tweak depuis le début, mais avaient été retirés du plugin original je crois. ils étaient source de remplacements intempestifs, il s'agissait d'un choix à faire que j'ai dû faire (temporairement?) en autorisant le remplacement si un espace, tiret ou point suivait le texte à remplacer.
En ce qui concerne le fork non backporté, c'est tout simplement parce que, même si la cohabitation du plugin original et du tweak est assurée, je ne peux pas tester *tous* les plugins à la fois et que tweak-spip est un projet à connotation unificatrice. C'est toujours délicat vis à vis de l'auteur de backporter des améliorations (on n'est jamais à l'abri de bugs introduits...) ou en tout cas des améliorations. D'ailleurs, a contrario, peu de modifs ont eu lieu sur tweak-spip alors que j'ai clairement déclaré que le code pouvait être pris en main par quiconque.
Je me suis mis dans l'idée que c'était plus facile pour les auteurs de petits plugins de s'inspirer de l'environnement tweak-spip s'ils avaient l'envie et le temps de revenir sur leur travail, plutôt qu'à l'inverse pour moi de contacter tous les auteurs pour leur proposer des idées.
Pour en revenir au côté unificateur de tweak-spip, il me semble que l'idée de réunir tous les remplacements typographiques est bonne (tous les tweaks de typos sont activés pour ma part). Sans revenir sur la maintenance facilitée ou le gain de performance possible, tweak-spip offre par exemple un système unifié de protection des balises (html|code|cadre|frame|script|cite|oucellesquonveut) que n'offrent pas les plugins originaux, alors que certains auteurs ont été contactés à ce sujet. Ce système est utilisé par 10 tweaks. Je ne vais pas chercher non plus à multiplier mon travail.
Pat.
Les tweaks ne sont que des "petites bidouilles" (nom que je préconise
pour ce plugin, d'ailleurs, plutôt que tweak-spip).
+1
-- Franck
spipcarto a écrit :
Fil a écrit :
Ce que je veux dire, c'est qu'il me semble dommage de conserver un
fork, sauf s'il y a une raison convaincante de le faire.
Ca faisait un peu partie de mon idée de départ en voyant que certains plugins ne font qu'une seule ligne : ça parait un peu lourd de garder un plugin complet pour ça, ça fait bcp de manip pour peu à l'arrivée. Si un débutant se pointe, tweak-spip est son ami. si un expert se pointe, il saura peut-être se passer de tweak-spip, mais saura aussi facilement remplir ses fichiers d'options ou de fonctions...
Du coup, la présence du plugin est forcément remise en cause. Un plugin pour une ligne dans mes_options, une balise ou un filtre, ça vaut pas le coup.
L'idée des tweaks est séduisante, et dans la mesure où chaque tweak est activable
indépendamment des autres, ça ne me paraît pas poser de problème ;
Chaque tweak est indépendant et une fois un tweak désactivé, les fichiers attachés peuvent même être supprimés si on veut gagner quelques Ko de place...
L'idée de depart de tweaks, c'est, si j'ai bien compris :
- de faciliter l'installation (je suis moyennement convaincu, mais bon...)
l'installation de? spip? bof... des plugins? oui... dans la mesure où il n'y en a qu'un à installer.
tweak-spip facilite surtout la manipulation des diverses variables de spip ou de personnalisation des tweaks en occupant une seule page de configuration. Vous avez sans doute remarqué que les plugins s'insèrent souvent sous le bouton 'Configuration' et le sous-menu devient une super rallonge !! Là, c'est peut-être pas encore parfait, mais c'est fonctionnel. Rien de plus facile pour modifier une variables de tweak-spip, même s'il faut au moins trois clics pour y arriver : 'Configuration', 'Tweak Spip' et le tweak en question.
- de ne pas surcharger le path (40 plugins, ca doit commencer à se sentir en perf...)
c'est clair. Mais cédric y travaille 
- de garantir la compatibilité entre differents ajouts fonctionnels (et ca, c'est pas rien !)
oui, cet aspect des choses s'est posé plusieurs fois au cours du développement du plugin ou des tweaks.
Je rajouterai à ta liste, spipcarto, la garantie de compatibilité avec spip lui-même qui introduit sans cesse de petites choses concernant les plugins, quitte même à les casser : cf <chemin>
Tweaks-Spip regroupe plus de trente fonctionnalités, t'imagines 30 plugins !?
Meme si on considere que tweaks est l'emplacement naturel d'une fonctionnalité comme la BTE, je ne vois pas pourquoi celle-ci devrait se fondre dans tweaks et s'encombrer de toutes les contraintes qui vont avec.
Suis pas trop d'accord. le BTE (euh, l'extensible ? je sais plus...) semble avoir une vie à part, foisonnante et pleine d'avenir vue la multitude de besoins concernant l'édition des articles. tweak-spip est censé rassembler des choses simples. tu veux casser le système de plugins original de spip ? (rires). tweak-spip n'a pas à être une usine complexe et parallèle à ce que fait déjà très bien spip avec son système de plugins.
Pour pouvoir developper et ameliorer, il faut souvent tout casser.
Se fixer une compatibilité arriere, c'est deja bien, mais si il faut verifier que les developpements des 12 modules autour restent compatibles, plus personne ne bouge !
allez, un trunk dans la zone ? je travaille actuellement sur une page de test rassemblant certains modules à surveiller en cas de modifs importantes du code.
D'autre part, tu parles de sécurité, perf, ergo... , j'ajouterai fiabilité et longévité.
Quand j'utilise du code, je regarde qui l'a produit, ca me donne une idée de la qualité et de l'activité que je vais rencontrer.
si tu veux on prend un café ?
Si j'utilise la BTE, spip-forms ou spip-liste, c'est en partie parce que je sais que les developpements ne vont pas s'arreter demain, et que si je leve un gros bug, j'aurai des gens à qui en parler, avec qui trouver la meilleure solution. Alors tweaks ... je regarderai dans 1 ou 2 ans (c'est pas vrai hein, mais c'est l'idée).
pour l'instant, rien de prévu dans un sens non pérenne. J'essaie de documenter le code au maxi, de solidifier et de simplifier au maximum le plugin. Un système de logs détaillés est en place dans le plugin. Cette liste et ses adeptes sont une mine d'or pour améliorer les choses. Un commit important va bientôt arriver, la gestion des variables a été améliorée.
Enfin, pour revenir sur le developpement collaboratif, d'experience, je dirais que le fork est souvent une etape necessaire.
Quand je tatonne sur une fonctionnalité, je ne vais pas aller casser le developpement de quelqu'un.
Je copie, je modifie, ca peut prendre longtemps donc je me retrouve rapidement de fait en situation de fork.
Quand c'est operationnel, je regarde comment réintegrer mes developpements au plugin d'origine, je peux discuter concretement avec l'auteur : lui sait ce qui a bougé depuis et pourquoi, moi je sais quelles modifs ont été faites pour ajouter la fonctionnalité, ce qui m'a compliqué la vie, bref, c'est le plus efficace car c'est un vrai echange, pas une succession de monologues.
+1. Joli résumé.
Bref, le gros plugin qui concentrerait plein de choses devenant le seul lieu possible de developpement, je ne crois vraiment pas que ca soit une bonne idée.
Attention, je pense que l'idée de départ est bonne : il faut regrouper les fonctionnalités dans un seul et meme plugin, mais j'appelerai ca un plugin d'integration.
Cette piste me paraît indispensable à spip de toute façon. A voir comment l'exploiter au mieux.
Pat.
Fil a écrit :
Les tweaks ne sont que des "petites bidouilles" (nom que je préconise
pour ce plugin, d'ailleurs, plutôt que tweak-spip).
Eh oui, pkoi pas ! Tout le monde est d'accord ?
...mais "bidouille" c'est pas un peu péjoratif ?
Déjà que je perçois parfois une certaine interrogation dans cette liste concernant l'utilité d'assembler diverses fonctionnalités...
ce qui m'intéresse là c'est surtout *rassurer* les utilisateurs et m'appuyer sur l'expérience de chacun ici pour faire qqchose de clair, simple et solide.
Le truc marrant qui ressort parfois est que certains se disent "mais si j'ai pas besoin de ci ou de ça, comment je fais pour prendre uniquement ce dont j'ai besoin?" Bref, la remarque qui tue...
je répète pour tous : un tweak désactivé ne nuit plus du tout
La plupart de ces petites bidouilles se limitent à une ou deux lignes, et appellent bien souvent des trucs non documentés du core...
Oui ! Je compte un peu sur les devs de Spip pour m'aider dans cette tâche... tweak-spip prend en compte les versions de spip, ce qui permet d'offrir des configurations adaptées, anciennes ou avant-gardistes !
Tandis que la BTE est une énorme bidouille, qui a donc vocation à rester en plugin autonome.
Bien sûr.
Pat
...mais "bidouille" c'est pas un peu péjoratif ?
Ben on est des bidouilleurs, ou on l'est pas ; je crois qu'il faut assumer
C'est une traduction de hacks.
Mais "petits réglages" c'est pas mal non plus.
Depuis qu'on a changé "Widgets" en "Crayons" on a vu que ça changeait
totalement l'attitude des utilisateurs. Dans un cas ils perçoivent un
truc geek, distant et qui fait peur ; dans l'autre ils ne le
perçoivent pas et l'installent sans a priori.
je répète pour tous : un tweak désactivé ne nuit plus du tout
Tout ça c'est de l'interface. Par exemple, plutôt que des cases à
cocher (qui te donnent l'impression que le tweak "est là mais ne
s'active pas"), mettre un système avec deux listes, et un transfert
d'une liste vers l'autre, te donnerait plus le sentiment d'"ajouter
des choses". Cela dit c'est un peu plus lourd à programmer, et pas
forcément standard. Une autre solution pourrait être de passer en
grisé l'intitulé des bidouilles non sélectionnées.
-- Fil
Pat a écrit :
spipcarto a écrit :
L'idée de depart de tweaks, c'est, si j'ai bien compris :
- de faciliter l'installation (je suis moyennement convaincu, mais bon...)
l'installation de? spip? bof... des plugins? oui... dans la mesure où il n'y en a qu'un à installer.
je disais bof parce que cocher un plugin ou un tweaks ... c'est pas trop dur.
Le probleme c'est de transferer le plugin, mais si tu as su faire 1 ftp pour 1, tu dois savoir le faire pour les autres ...
tweak-spip facilite surtout la manipulation des diverses variables de spip ou de personnalisation des tweaks en occupant une seule page de configuration.
Ca par contre, ca aurait plutot sa place dans Spip.
Meme si c'est bien pratique, je ne vais pas utiliser ca pour mes plugins, pour ne pas les rendre dépendants...
Vous avez sans doute remarqué que les plugins s'insèrent souvent sous le bouton 'Configuration' et le sous-menu devient une super rallonge !! Là, c'est peut-être pas encore parfait, mais c'est fonctionnel. Rien de plus facile pour modifier une variables de tweak-spip, même s'il faut au moins trois clics pour y arriver : 'Configuration', 'Tweak Spip' et le tweak en question.
Mouais, question ergonomie, c'est vrai qu'on manque de cadre.
Perso je tape l'incruste sur la page configuration de spip en ajoutant des onglets, mais on est vite limité...
Mais la meilleure soluce reste un lien dans le descriptif du plugin, ca suffit pour une page de configuration.- de ne pas surcharger le path (40 plugins, ca doit commencer à se sentir en perf...)
c'est clair. Mais cédric y travaille
au dela de ca, regrouper les transformation du texte en un seul passage de regexp ... c'est mieux !
- de garantir la compatibilité entre differents ajouts fonctionnels (et ca, c'est pas rien !)
oui, cet aspect des choses s'est posé plusieurs fois au cours du développement du plugin ou des tweaks.
Je rajouterai à ta liste, spipcarto, la garantie de compatibilité avec spip lui-même qui introduit sans cesse de petites choses concernant les plugins, quitte même à les casser : cf <chemin>
Tweaks-Spip regroupe plus de trente fonctionnalités, t'imagines 30 plugins !?
bah oui.
De base j'en active une dizaine, ca me choque pas.
Le probleme, c'est juste les perfs, mais sinon, au niveau maintenance, je prefere.
Le tout, c'est de distribuer un spip avec les plugins qui vont avec, pour que ca ne soit pas la chasse aux tresors pour l'utilisateur...
Meme si on considere que tweaks est l'emplacement naturel d'une fonctionnalité comme la BTE, je ne vois pas pourquoi celle-ci devrait se fondre dans tweaks et s'encombrer de toutes les contraintes qui vont avec.
Suis pas trop d'accord. le BTE (euh, l'extensible ? je sais plus...)
l'extensible, c'est un fork maison, la vraie BTE est maintenant extensible (comprendre : elle a des points d'entrée pour ajouter des raccourcis et les boutons qui vont avec)
semble avoir une vie à part, foisonnante et pleine d'avenir vue la multitude de besoins concernant l'édition des articles. tweak-spip est censé rassembler des choses simples. tu veux casser le système de plugins original de spip ? (rires). tweak-spip n'a pas à être une usine complexe et parallèle à ce que fait déjà très bien spip avec son système de plugins.
Je me suis planté, je croyais que ca parlait BTE.
Mais c'est un bon exemple car elle ajoute de la syntaxe et donc traite le texte.
De mon coté j'ai voulu l'etendre pour ajouter un truc.
La logique "Spip" aurait voulu que je fasse un plugin indépendant (ce que j'ai fait au debut).
Mais au niveau perf, repasser dans la moulinette complete alors que la BTE fait deja un passage pour X raccourcis ... c'est bete.
J'ai donc fait un plugin de plugin, un petit truc qui rajoute une fonctionnalité à un plugin existant.
Je pense que pour tweaks, ca pourrait etre une bonne approche.
Pour pouvoir developper et ameliorer, il faut souvent tout casser.
Se fixer une compatibilité arriere, c'est deja bien, mais si il faut verifier que les developpements des 12 modules autour restent compatibles, plus personne ne bouge !
allez, un trunk dans la zone ? je travaille actuellement sur une page de test rassemblant certains modules à surveiller en cas de modifs importantes du code.
D'autre part, tu parles de sécurité, perf, ergo... , j'ajouterai fiabilité et longévité.
Quand j'utilise du code, je regarde qui l'a produit, ca me donne une idée de la qualité et de l'activité que je vais rencontrer.
si tu veux on prend un café ?
Avec plaisir (ou une biere ...)
C'etait juste pour faire remarquer que le regroupement, de fait, ca fait un nivellement par le bas.
Si j'utilise la BTE, spip-forms ou spip-liste, c'est en partie parce que je sais que les developpements ne vont pas s'arreter demain, et que si je leve un gros bug, j'aurai des gens à qui en parler, avec qui trouver la meilleure solution. Alors tweaks ... je regarderai dans 1 ou 2 ans (c'est pas vrai hein, mais c'est l'idée).
pour l'instant, rien de prévu dans un sens non pérenne. J'essaie de documenter le code au maxi, de solidifier et de simplifier au maximum le plugin. Un système de logs détaillés est en place dans le plugin. Cette liste et ses adeptes sont une mine d'or pour améliorer les choses. Un commit important va bientôt arriver, la gestion des variables a été améliorée.
Encore une fois, c'etait juste pour l'idée generale, j'ai rien contre toi ni contre tweaks, c'est juste pour dire qu'une communauté, c'est aussi des gens qui se connaissent plus ou moins et qui peuvent ou non bosser ensemble.
La encore, le regroupement, dès la phase de developpement, a plutot tendance à etre un frein.
Bref, le gros plugin qui concentrerait plein de choses devenant le seul lieu possible de developpement, je ne crois vraiment pas que ca soit une bonne idée.
Attention, je pense que l'idée de départ est bonne : il faut regrouper les fonctionnalités dans un seul et meme plugin, mais j'appelerai ca un plugin d'integration.
Cette piste me paraît indispensable à spip de toute façon. A voir comment l'exploiter au mieux.
Je vais faire une tentative de distribution de spip bientot, on verra si ca a un interet ou pas.
L'idée pour moi, c'est de faire un gros Spip avec plein de plugins, des squelettes parametrables ... bref, une grosse usine à gaz dont chacun n'exploitera qu'un tout petit bout, mais qui contiendra tout ce qui peut etre utile sans se poser la question de la version et des compatibilités.
(faut que je regarde tweaks du coup, je ne pensais pas l'integrer...)
@++
Fil a écrit :
...mais "bidouille" c'est pas un peu péjoratif ?
Ben on est des bidouilleurs, ou on l'est pas ; je crois qu'il faut assumer
C'est une traduction de hacks.
alors j'assume Mais un plugin doit pas forcément prendre le caractère de ses auteurs mdr
Mais "petits réglages" c'est pas mal non plus.
Oui, ça fait un plus sérieux. et pkoi "petits" ? "petits" paske "mignons" ?
c'est "petit" en code, mais ça sauve sans doute la vie de certains utilisateurs
ou : "Réglages", "Affûtages", "Ajustements"
"Affûtages", ou "Affutages" ça me plaît bien.
Depuis qu'on a changé "Widgets" en "Crayons" on a vu que ça changeait
totalement l'attitude des utilisateurs. Dans un cas ils perçoivent un
truc geek, distant et qui fait peur ; dans l'autre ils ne le
perçoivent pas et l'installent sans a priori.
oui, "crayons" est une belle trouvaille. "widgets" je savais même pas ce que ça voulait dire... le nom du plugin est important.
Tout ça c'est de l'interface. Par exemple, plutôt que des cases à
cocher (qui te donnent l'impression que le tweak "est là mais ne
s'active pas"), mettre un système avec deux listes, et un transfert
d'une liste vers l'autre, te donnerait plus le sentiment d'"ajouter
des choses". Cela dit c'est un peu plus lourd à programmer, et pas
forcément standard. Une autre solution pourrait être de passer en
grisé l'intitulé des bidouilles non sélectionnées.
là-dessus, c'est vrai que l'interface pour l'instant est basique... il faut l'améliorer à terme, j'en suis pas encore tout à fait là.
la page de config affiche même toutes les fonctionnalités, y compris celles qui ne sont pas compatibles avec la version courante de spip...
Pat
L'idée pour moi, c'est de faire un gros Spip avec plein de plugins, des
squelettes parametrables ... bref, une grosse usine à gaz dont chacun
n'exploitera qu'un tout petit bout, mais qui contiendra tout ce qui peut
etre utile
ben moi j'ai déjà ça : j'ai spip + toute la zone dans plugins/
Cela dit on a vraiment besoin d'un outil dans admin_plugins qui nous
donnerait une liste de plugins existants, et qui permette de les
télécharger/mettre à jour.
-- Fil
spipcarto a écrit :
je disais bof parce que cocher un plugin ou un tweaks ... c'est pas trop dur.
Le probleme c'est de transferer le plugin, mais si tu as su faire 1 ftp pour 1, tu dois savoir le faire pour les autres ...
Bien sûr, c'est le lot de tous les plugins. Le téléchargement en direct des fonctionnalités est séduisant. je garde un oeil sur les travaux des uns et des autres. c'est sûr que passer par le ftp trop souvent n'est pas synonyme de facilité, mais bon... c'est pas trop difficile non plus, c'est un peu la base : pour un loader il faut bien le placer en ftp d'abord.
tweak-spip facilite surtout la manipulation des diverses variables de spip ou de personnalisation des tweaks en occupant une seule page de configuration.
Ca par contre, ca aurait plutot sa place dans Spip.
Meme si c'est bien pratique, je ne vais pas utiliser ca pour mes plugins, pour ne pas les rendre dépendants...
togg a bossé dans ce sens...
Perso je tape l'incruste sur la page configuration de spip en ajoutant des onglets, mais on est vite limité...
tweak-spip fait idem !
Mais la meilleure soluce reste un lien dans le descriptif du plugin, ca suffit pour une page de configuration.
j'ai déjà pensé à ça, mais il faudrait une nouvelle fonction dans spip... ou alors un <?php generer_url_ecrire()?> dans les fichiers de langue ?
au dela de ca, regrouper les transformation du texte en un seul passage de regexp ... c'est mieux !
oui, mais donner la possibilité de choisir à l'utilisateur dégrade forcément les perfs, à moins d'ajouter une certaine forme de 'compilation'... j'ai cherché des pistes pour 'compiler' par exemple la $table_des_traitements : la somme des tweaks activés ne génère au final qu'une seule ligne pour $table_des_traitements.
J'ai donc fait un plugin de plugin, un petit truc qui rajoute une fonctionnalité à un plugin existant.
Je pense que pour tweaks, ca pourrait etre une bonne approche.
C'est un peu déjà le cas... sauf que tous les plugins de plugins (les tweaks), par défaut, sont là et activables en un seul clic.
si tu veux on prend un café ?
Avec plaisir (ou une biere ...)
ok pour la bière ! en général suis sur paris
C'etait juste pour faire remarquer que le regroupement, de fait, ca fait un nivellement par le bas.
c'est un dosage savant à trouver.
Encore une fois, c'etait juste pour l'idée generale, j'ai rien contre toi ni contre tweaks, c'est juste pour dire qu'une communauté, c'est aussi des gens qui se connaissent plus ou moins et qui peuvent ou non bosser ensemble.
on finit par percevoir un peu le caractère des gens ici en lisant leurs textes. compatibilités/incompatibilités, rien de plus normal, ça me choque pas. si la communauté est trop fermée, les utilisateurs vont forker dans leur coin et se débrouiller au plus rapide pour arriver à leur fin. si la communauté est ouverte, pas facile la cohabitation... c une question de vivre ensemble. au noyau dur de décider quel ton à donner !
le succès de spip repose sur l'extème vivacité du projet et de ses fans.
L'idée pour moi, c'est de faire un gros Spip avec plein de plugins, des squelettes parametrables ... bref, une grosse usine à gaz dont chacun n'exploitera qu'un tout petit bout, mais qui contiendra tout ce qui peut etre utile sans se poser la question de la version et des compatibilités.
toi aussi tu fais du regroupement nivelé par le bas alors ! (rires)
Pat.
* spipcarto tapotait, le 16/04/2007 16:16:
(au sujet de la BTE)
J'ai donc fait un plugin de plugin, un petit truc qui rajoute une fonctionnalité à un plugin existant.
Résultat, ça m'a donné la matière première pour éclater la BTE en 2 plugins :
- un pour l'ergonomie de la BT
- un pour les raccourcis typo supplémentaires.
Merci spipcarto !
--
RealET