Log:
rajout dossier thickbox, avec insertion icone prev et next, modif css en consequence
(dispo pas parfaite... a ameliorer)
C'est un peu dommage de dupliquer des plugins comme ça. Ca alourdit la
zone ; vous ne bénéficierez pas des corrections de bugs ; etc.
Ca montre en tous cas que, ce qui manque dans SPIP c'est la
possibilité d'installer des plugins en deux clics (y a presque tout
ici et là, mais pas intégré en standard).
-- Fil
Fil a écrit :
Log:
rajout dossier thickbox, avec insertion icone prev et next, modif css en consequence
(dispo pas parfaite... a ameliorer)
C'est un peu dommage de dupliquer des plugins comme ça. Ca alourdit la
zone ; vous ne bénéficierez pas des corrections de bugs ; etc.Ca montre en tous cas que, ce qui manque dans SPIP c'est la
possibilité d'installer des plugins en deux clics (y a presque tout
ici et là, mais pas intégré en standard).-- Fil
Euh Fil isn't Mister mode diplomatique? (ou les leçons de la courtoisie et de la gentillesse) c'est non seulement dommage mais ce n'est pas intéressant du tout d'intégrer des plugins figés!!!
si il y avait moyen pour des squelettes complets de seulement proposer d'activer des chargements de plugins (une liste xml) se serait super (un peu comme une liste sous linux?), en attendant ne faites pas des utilisateurs des manchots, dites qu'il faut tel et tel plugin...
Ainsi, les squelettes complets auraient des plugins qui s'améliorent et permettent que l'utilisateur soit libre de les rajouter lui même sans nuire au site, ceci dit ç'est vrai que certains plugins deviennent vite indispensables dès l'installation 
mes 2 sous
rose
touti wrote:
Fil a écrit :
Log:
rajout dossier thickbox, avec insertion icone prev et next, modif css en consequence
(dispo pas parfaite... a ameliorer)
C'est un peu dommage de dupliquer des plugins comme ça. Ca alourdit la
zone ; vous ne bénéficierez pas des corrections de bugs ; etc.Ca montre en tous cas que, ce qui manque dans SPIP c'est la
possibilité d'installer des plugins en deux clics (y a presque tout
ici et là, mais pas intégré en standard).-- Fil
Euh Fil isn't Mister mode diplomatique? (ou les leçons de la courtoisie et de la gentillesse) c'est non seulement dommage mais ce n'est pas intéressant du tout d'intégrer des plugins figés!!!
si il y avait moyen pour des squelettes complets de seulement proposer d'activer des chargements de plugins (une liste xml) se serait super (un peu comme une liste sous linux?), en attendant ne faites pas des utilisateurs des manchots, dites qu'il faut tel et tel plugin...
Ainsi, les squelettes complets auraient des plugins qui s'améliorent et permettent que l'utilisateur soit libre de les rajouter lui même sans nuire au site, ceci dit ç'est vrai que certains plugins deviennent vite indispensables dès l'installation
mes 2 sous
rose
chargeur fournit le chargement par une action, rien n'empèche un squelette ou un autre plugin de la déclencher. Pour rappel, de n'importe quel zip, pas seulement les spip et avec actions de renommage/post-édition.
Pour le 2 clicks, effectivement il faut que ce soit reliè à une liste de plugins sur un serveur. Simplement, j'ai peur qu'une boite de sélection avec une centaine de lignes soit un peu rédhibitoire. Il faudrait des catégories. L'état peut déjà servir ici. De tout façon, on n'a pas encore de tags sur les plugins. Peut-être qu'un jour on pourrait copier ceux de contrib ?
Sinon, j'avais essayé d'entamer une discussion sur les mises en commun par les plugins. Je pensais à l'exemple de Geshi qui serait utilisé par 4 plugins. Je pense faire un plugin geshi sui ne contiendrait que la lib, et rendre coloration_code(s) et spixplorer dépendants dessus.
Kent1 citait justement les plugins jQuery comme datePicker. thickbox est évidemment aussi un bon exemple.
Dans ce domaine des dépendances, je prévois de les faire traiter automatiquement par chargeur si l'utilisateur est d'accord ... et si elles sont spécifiées dans le machin.xml
Finalement, le dialogue chargeur serait:
* url dépot , défaut Téléchargements - Plugins SPIP
* dépendances auto : O/N défaut oui
* type plugin/theme/squelette (1) défaut plugin
* état: stable/test/dev/tous défaut stable
* paquets: un select multiple déduit des paramètres précédents
Bien sûr, coté serveur cela nécessiterait une liste simplifiée (xml ou simple csv) qu'on pourrait facilement fabriquer comme les rss.
(1) J'avais aussi proposé que nous créions un type squelette.xml afin de pouvoir les intégrer dans la machine paquets. Je crois que theme.xml ne répond pas à la même attente.
--
toggg
bertrand Gugger a écrit :
chargeur fournit le chargement par une action, rien n'empèche un squelette ou un autre plugin de la déclencher. Pour rappel, de n'importe quel zip, pas seulement les spip et avec actions de renommage/post-édition.
excuse moi, il suffit que je décroche un peu et je m'y perds, ou est chargeur?
Pour le 2 clicks, effectivement il faut que ce soit reliè à une liste de plugins sur un serveur. Simplement, j'ai peur qu'une boite de sélection avec une centaine de lignes soit un peu rédhibitoire. Il faudrait des catégories. L'état peut déjà servir ici. De tout façon, on n'a pas encore de tags sur les plugins. Peut-être qu'un jour on pourrait copier ceux de contrib ?
Je comprends rien
Je suppute que tu verrais tous les plugins téléchargeables depuis une liste intégrée à spip?
amha c'est pas très intéressant car tout est déjà en ligne pour choisir parmi tous ces 1001 plugins, ou alors penser à forcer une install comme avec firefox ? je vois pas comment faire vraiment...
Bref, j'imaginais plutot un système de dépendances vis à vis d'un squelette donné avec seulement qqs plugins qui lui sont nécessaires, une sorte de spip_loader_plugins?
Tu nous montres un exemple de fonctionnement sur un plugin simple dépendant d'un squelette?
Sinon, j'avais essayé d'entamer une discussion sur les mises en commun par les plugins. Je pensais à l'exemple de Geshi qui serait utilisé par 4 plugins. Je pense faire un plugin geshi sui ne contiendrait que la lib, et rendre coloration_code(s) et spixplorer dépendants dessus.
Kent1 citait justement les plugins jQuery comme datePicker. thickbox est évidemment aussi un bon exemple.Dans ce domaine des dépendances, je prévois de les faire traiter automatiquement par chargeur si l'utilisateur est d'accord ... et si elles sont spécifiées dans le machin.xml
Finalement, le dialogue chargeur serait:
* url dépot , défaut Téléchargements - Plugins SPIP
* dépendances auto : O/N défaut oui
* type plugin/theme/squelette (1) défaut plugin
* état: stable/test/dev/tous défaut stable
* paquets: un select multiple déduit des paramètres précédentsBien sûr, coté serveur cela nécessiterait une liste simplifiée (xml ou simple csv) qu'on pourrait facilement fabriquer comme les rss.
(1) J'avais aussi proposé que nous créions un type squelette.xml afin de pouvoir les intégrer dans la machine paquets. Je crois que theme.xml ne répond pas à la même attente.
touti wrote:
bertrand Gugger a écrit :
chargeur fournit le chargement par une action, rien n'empèche un squelette ou un autre plugin de la déclencher. Pour rappel, de n'importe quel zip, pas seulement les spip et avec actions de renommage/post-édition.
excuse moi, il suffit que je décroche un peu et je m'y perds, ou est chargeur?
http://trac.rezo.net/trac/spip-zone/browser/_plugins_/_test_/chargeur
Pour le 2 clicks, effectivement il faut que ce soit reliè à une liste de plugins sur un serveur. Simplement, j'ai peur qu'une boite de sélection avec une centaine de lignes soit un peu rédhibitoire. Il faudrait des catégories. L'état peut déjà servir ici. De tout façon, on n'a pas encore de tags sur les plugins. Peut-être qu'un jour on pourrait copier ceux de contrib ?
Je comprends rien
Je suppute que tu verrais tous les plugins téléchargeables depuis une liste intégrée à spip?
Pas intégrée à spip, mais disponible sur les serveurs de zip. Sur http://files.spip.org/ ou tout serveur implémentant les paquets comme chez Arnaud, cette liste serait facilement générable de là même façon (xslt) que les rss à partie de paquets.xml . Sur un site spip comme contrib, ce pourrait être une bête boucle sur les documents de type zip (avec sans doute une sélection par mot clé)
Evidemment, tout cela est ouvert à n'importe qui, je ne cite ces serveurs que parce que c'est notre noyau dur. On pourrait même envisger un système genre pingback sur spip.net ou org qui permettrait à un site de dire: hey ! moi je propose tel ou tel plugin ou squelette...
amha c'est pas très intéressant car tout est déjà en ligne pour choisir parmi tous ces 1001 plugins, ou alors penser à forcer une install comme avec firefox ?
Pas forcer une install, mais proposer une liste où l'utilisateur choisit. Eventuellement, avec tout ce qu'on a maintenant dans le paquets.xml, on peut lui donner le descriptif, l'état, les dépendances, savoir si des tables supplémentaires sont créées, etc.
Tout est déjà en ligne, mais tout le monde ne surveille pas contrib ou la zone ... la preuve, tu ne connaissais pas chargeur 
Je pense qu'une liste triable et filtrable sui de plus permettrait de donner rapidement un résumé pourrait être intéressante. Ensuite, ne pas avoir à chercher "à la main" les dépendances, surtout si on morcelle les paquets pour mettre en commun ce qui devrait/pourrait l'être
Bref, j'imaginais plutot un système de dépendances vis à vis d'un squelette donné avec seulement qqs plugins qui lui sont nécessaires, une sorte de spip_loader_plugins?
Pour les dépendances, c'est le plugin.xml (et je l'espère le squelette.xml) qui les spécifie grâce à l'élément <necessite>
Sauf erreur, cet élément est capable de donner les versions min/max nécessaire.
D'ailleurs j'oubliais de préciser que <necessite> permet aussi de donner la version spip qui va bien. La liste ne retiendrait donc que ce qui est compatible.
Aussi, pour ce qui est installé, on ne proposerait que ce qui a évolué.
Tu nous montres un exemple de fonctionnement sur un plugin simple dépendant d'un squelette?
J'imaginais ça plutôt dans les sens contraire, le squelette qui nécessite tel ou tel plugin ce qu'il préciserait par son squelette.xml
Non, je n'ai pas de demo...
Comme le dit Fil, on voit tous les morceaux nécessaires se mettre en place, mais ça n'est pas encore fini
--
toggg