gilles.vincent@gmail.com a écrit :
Author: gilles.vincent@gmail.com
Date: Thu Sep 7 20:22:41 2006
New Revision: 5180Log:
Nouveau répertoire pour héberger les thèmes SpipAdded:
_contribs_/_themes_/
en fait il existe déjà, je trouve qu'il n'est pas sa place cependant.
_plugins_branche_stable_\_spip_1_9_0_\_themes_
devrait être
_plugins_\_themes_
tout simplement.
--
James
James a écrit :
en fait il existe déjà, je trouve qu'il n'est pas sa place cependant.
_plugins_branche_stable_\_spip_1_9_0_\_themes_devrait être
_plugins_\_themes_
tout simplement.
en fait, moi, j'ai rien compris ...
on met quoi, ou ?
dans le doute, je travail sur dev,mais peux tu rappeler la regle STP ?
par exemple, spipcarto n'est compatible qu'avec la 1.9.1, il doit aller dans la branche ?
ou plutot une copie dans la branche stable et une branche dev (pas utile pour le moment) ?
widget_calendar a l'air compatible 1.9.0 et 1.9.1, il doit aller dans dev ? rester dans 1_9_0 ? etre dupliqué ?
help !
@++
PS : et je parle pas des utilisateurs ... entre ceux qui ralent qu'on ne devrait pas diffuser des trucs pas finis et ceux qui ralent qu'on ne trouve pas les plugins, c'est la zone !
:o)
Stephane LAURENT a écrit :
James a écrit :
en fait il existe déjà, je trouve qu'il n'est pas sa place cependant.
_plugins_branche_stable_\_spip_1_9_0_\_themes_devrait être
_plugins_\_themes_
tout simplement.
en fait, moi, j'ai rien compris ...
on met quoi, ou ?
dans le doute, je travail sur dev,mais peux tu rappeler la regle STP ?par exemple, spipcarto n'est compatible qu'avec la 1.9.1, il doit aller dans la branche ?
ou plutot une copie dans la branche stable et une branche dev (pas utile pour le moment) ?widget_calendar a l'air compatible 1.9.0 et 1.9.1, il doit aller dans dev ? rester dans 1_9_0 ? etre dupliqué ?
help !
@++
euh... mon avis (perso hein) c'est que j'aime pas cette histoire de branche tel qu'il existe
Donc, tout dans _plugins_/ !
Plus sérieusement, catégoriser les plugins c'est une bonne chose. Par contre, je trouve que c'est *dans* le plugin qu'il devrait y avoir les branches....
exemple:
_plugins_/_squelettes_/_blip_/dev pour le dev courant, le trunk
_plugins_/_squelettes_/_blip_/branches/
_plugins_/_squelettes_/_blip_/branches/1.9.0/ pour la version stable pour spip 1.9.0
_plugins_/_squelettes_/_blip_/branches/1.9.1/ pour la version stable pour spip 1.9.1
etc...
exemple hein
pour l'instant tout ce que je fais est en dev et j'ai pas thématisé alors voilà ... j'ai tout dans _plugins_/ 
--
James
Hello,
petite question je place mes fichiers sous
_contribs_/_themes_/
ou
_plugins_branche_stable_\_spip_1_9_0_\_themes_ (avec ceux de Romy)
mais si je peux me permettre un avis, je suis d'accord avec James pour les plugins
chaque plugin devrai gérer sa compatibilité avec 1.9.0, 1.9.1 ...
mais je viens d'arrivé alors je fais comme vous dites
Le 7 sept. 06 à 20:32, James a écrit :
gilles.vincent@gmail.com a écrit :
Author: gilles.vincent@gmail.com
Date: Thu Sep 7 20:22:41 2006
New Revision: 5180Log:
Nouveau répertoire pour héberger les thèmes SpipAdded:
_contribs_/_themes_/en fait il existe déjà, je trouve qu'il n'est pas sa place cependant.
_plugins_branche_stable_\_spip_1_9_0_\_themes_
devrait être
_plugins_\_themes_
tout simplement.
--
James
_______________________________________________
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone
A priori les themes sont indépendants de la version de Spip (en gros).
Par contre, à y réfléchir, themes n’a sa place ni dans contribs ni dans plugins :
à mon avis ça devrait être un répertoire à la racine, car c’est du même ordre.
Le 07/09/06, Skedus <skedus@free.fr> a écrit :
Hello,
petite question je place mes fichiers souscontribs/themes/
ou
plugins_branche_stable_spip_1_9_0__themes_ (avec ceux de Romy)mais si je peux me permettre un avis, je suis d’accord avec James
pour les plugins
chaque plugin devrai gérer sa compatibilité avec 1.9.0, 1.9.1 …
mais je viens d’arrivé alors je fais comme vous ditesLe 7 sept. 06 à 20:32, James a écrit :
gilles.vincent@gmail.com a écrit :
Author: gilles.vincent@gmail.com
Date: Thu Sep 7 20:22:41 2006
New Revision: 5180Log:
Nouveau répertoire pour héberger les thèmes SpipAdded:
contribs/themes/en fait il existe déjà, je trouve qu’il n’est pas sa place cependant.
plugins_branche_stable_spip_1_9_0__themes_
devrait être
plugins_themes_
tout simplement.
–
James
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone
Gilles Vincent a écrit :
A priori les themes sont indépendants de la version de Spip (en gros).
Par contre, à y réfléchir, _themes_ n'a sa place ni dans _contribs_ ni dans
_plugins_ :
à mon avis ça devrait être un
répertoire à la racine, car c'est du même ordre..Gilles
Faux. ils sont lié à une version à cause des squelettes qu'on livre dans dist/ ,en tirant en peu par les cheveux, je veux bien l'admettre mais quand même
Vrai, à la racine car c'est du même ordre que _squelettes_ ou _logos_
ils se trouvent dans _plugins_/ pour bénéficier du système d'activation je crois. Ils entrent dans le spip_path plus facilement comme ça, on télécharge tout, on en choisit un, puis l'autre...
Pour le moment, je propose d'utiliser le répertoire "historique", _plugins_branche_stable_/_spip_1_9_0_/_themes_, pour l'instant et on que les participants décident si oui ou non, c'est plugin ou pas, si c'est racine ou pas....
--
James
pour moi, c’est à la racine car un thème ne s’active pas comme un plugin sauf cas très particulier :
un plugin fonctionne même si tu touches à tes squelettes, et apporte des fonctionnalités supplémentaires à SPIP.
Un thème est spécifique à un squelette de référence : celui de la dist/
Donc dès qu’on le touche, on risque de devoir l’adapter…
Par contre je suis d’accord avec le fait que c’est du même niveau qu’un squelette.
Je ne mettrais personnellement pas les thèmes dans une sous-arbo d’une sous-arbo, car il seront noyés parmis tout le reste alors que c’est vraiment un truc à part…
Pour ce qui est de la dépendance vis-à-vis d’une dist/ donnée, je pense qu’une info adéquate dans un petit Readme peut faire l’affaire (genre « testé sous Spip 1.86 et Spip 1.904 » 
)
Qu’en pensent les autres ?
Romy ?
Skedus?
Le 07/09/06, James <james@rezo.net> a écrit :
Gilles Vincent a écrit :
A priori les themes sont indépendants de la version de Spip (en gros).
Par contre, à y réfléchir, themes n’a sa place ni dans contribs ni dans
plugins :
à mon avis ça devrait être un
répertoire à la racine, car c’est du même ordre..Gilles
Faux. ils sont lié à une version à cause des squelettes qu’on livre dans
dist/ ,en tirant en peu par les cheveux, je veux bien l’admettre mais
quand mêmeVrai, à la racine car c’est du même ordre que squelettes ou logos
ils se trouvent dans plugins/ pour bénéficier du système d’activation
je crois. Ils entrent dans le spip_path plus facilement comme ça, on
télécharge tout, on en choisit un, puis l’autre…Pour le moment, je propose d’utiliser le répertoire « historique »,
plugins_branche_stable/spip_1_9_0/themes, pour l’instant et on que
les participants décident si oui ou non, c’est plugin ou pas, si c’est
racine ou pas…–
James
Flute j’étais en train de répondre à Gilles quand tous les mails arrivent, ça fuse sur spip-zone
Donc pour résumé
spip est distribué avec des squelettes de base répertoire ‹ dist ›
ici nous parlons de theme uniquement pour ces squelettes c’est pour cela qu’ils sont dans la catégorie plugin
car ils s’activent comme un plugin dans l’espace privé c’est un peu particulier
Maintenant il faut imaginer qu’il pourrai y avoir d’autres distri de squelettes (il y en a déja) auquel serai lié des thémes
dans l’absolu il faudrai quelque chose du genre
squelettes/
dist/
themes/
t1/
…
sk1/
themes/
les thémes correspondant aux css en fait.
et encore ici il n’y a pas l’info de version de squelette, ni de compatibilité avec la version de spip
glups il faut y réfléchir un peu plus
mais peut être que quelqu’un à déjà réfléchi aux thème sous spip ? je ne suis pas le mieux placé
je ne connais pas encore bien la structure de la spip-zone
mais pour ces themes en particuliers qui sont lié à la dist de spip il devrai peu être resté dans la partie plugin
cela permet à ceux qui découvre spip d’avoir accès rapidement à des thèmes avant de se lancer dans les squelettes
(et ça marche depuis que j’ai montré cela je connais déjà des gens qui sont passé ou vont passé sur spip)
pour les autres themes je ne sais vraiment pas.
Sur cela bonne nuit et à demain
Le 7 sept. 06 à 23:20, Gilles Vincent a écrit :
pour moi, c’est à la racine car un thème ne s’active pas comme un plugin sauf cas très particulier :
un plugin fonctionne même si tu touches à tes squelettes, et apporte des fonctionnalités supplémentaires à SPIP.
Un thème est spécifique à un squelette de référence : celui de la dist/
Donc dès qu’on le touche, on risque de devoir l’adapter…Par contre je suis d’accord avec le fait que c’est du même niveau qu’un squelette.
Je ne mettrais personnellement pas les thèmes dans une sous-arbo d’une sous-arbo, car il seront noyés parmis tout le reste alors que c’est vraiment un truc à part…Pour ce qui est de la dépendance vis-à-vis d’une dist/ donnée, je pense qu’une info adéquate dans un petit Readme peut faire l’affaire (genre « testé sous Spip 1.86 et Spip 1.904 »
Qu’en pensent les autres ?
Romy ?
Skedus?.Gilles
Le 07/09/06, James <james@rezo.net> a écrit :
Gilles Vincent a écrit :
A priori les themes sont indépendants de la version de Spip (en gros).
Par contre, à y réfléchir, themes n’a sa place ni dans contribs ni dans
plugins :
à mon avis ça devrait être un
répertoire à la racine, car c’est du même ordre..Gilles
Faux. ils sont lié à une version à cause des squelettes qu’on livre dans
dist/ ,en tirant en peu par les cheveux, je veux bien l’admettre mais
quand mêmeVrai, à la racine car c’est du même ordre que squelettes ou logos
ils se trouvent dans plugins/ pour bénéficier du système d’activation
je crois. Ils entrent dans le spip_path plus facilement comme ça, on
télécharge tout, on en choisit un, puis l’autre…Pour le moment, je propose d’utiliser le répertoire « historique »,
plugins_branche_stable/spip_1_9_0/themes, pour l’instant et on que
les participants décident si oui ou non, c’est plugin ou pas, si c’est
racine ou pas…–
James
Gilles Vincent a écrit :
pour moi, c'est à la racine car un thème ne s'active pas comme un plugin sauf cas très particulier :
Ben, amha, c'est pas vraiment un plugin dans le sens ou 2 plugins themes en meme temps, j'ai du mal à voir (quoi que, si c'est genre qui ajoute le papillon bleu qui bat des ailes en haut, pourquoi pas).
Par contre, un plugin gestionnaire de theme, la, je vois deja mieux.
Mais si on regarde bien, on voudra avoir un systeme d'activation, de facon à mettre 12 themes et à choisir (idealement comme preference utilisateur et non ?)
un plugin fonctionne même si tu touches à tes squelettes, et apporte des fonctionnalités supplémentaires à SPIP.
Un thème est spécifique à un squelette de référence : celui de la dist/
heu, oui et non ...
vous entendez quoi par "theme" ?
ca peut concerner l'espace privé, non ?
Et puis, c'est plus lié aux css qu'au squelettes (enfin, si les squlettes sont bien fait).
Meme si je ne suis pas point par point la dist, quand je fais des squelettes, je m'en inspire et j'utilise pas mal d'id et de classes identiques.
de toutes facons, il y a les classes spip, qui elles sont forcement utilisées et peuvent faire parti du theme.
donc, toujours amha, non, un theme n'est pas forcement lié à un squelette
Donc dès qu'on le touche, on risque de devoir l'adapter..
toujours pareil, idéalement, on complete, on ne modifie pas ... mais bon, ca, c'est quand on a le temps de bien travailler.
Tel que j'imagine le besoin, les themes sont à coté et gérés par un plugin qui assemble des css et regle le path comme il faut.
On peut comme ca imaginer plusieurs approches (preference utilisateur ou reglage du site par exemple)
mes 2 sous
@++
Skedus a écrit :
Flute j'étais en train de répondre à Gilles quand tous les mails arrivent, ça fuse sur spip-zone
Donc pour résumé
hihihi, moi j'ai tiré trop vite donc je suis à coté de la plaque ...
ceci dit une remarque reste sans doute valable : on active pas 2 themes en meme temps.
Mais bon, on peut en mettre plusieurs et choisir en les activant successivement, ce qui est deja bien
et puis on peut quand meme imaginer un plugin qui permette à l'utilisateur de choisir parmis les themes sous forme de plugins désactivés ....
@++
comme les themes sont exlusifs, il fauts qu’ils aient tous le meme prefixe dans leur definition plugin.xml
theme
Cedric
Bill a écrit :
Le 07 sept. 2006, à 21:56, Skedus a écrit :
petite question je place mes fichiers sous
_contribs_/_themes_/
ou
_plugins_branche_stable_\_spip_1_9_0_\_themes_ (avec ceux de Romy)
Je n'ai pas d'avis sur l'organisation des répertoires de plugins, par contre, il est logique de ranger les thèmes ensemble : ceux de Skedus avec le miens, celui d'IZO, et ceux de qui veut...
C'est donc par là :
C'est épatant, Skedus : tes plugins sont nickel, et marchent finger in ze nooz
Ce serait super qu'on te mette le pied à l'étrier pour que tu puisse commiter aussi au besoin (j'ose rien expliquer, moi qui sait à peine comment j'y parviens parfois). Y'a quelque info à ce sujet par là : Connexion · GitLab
Bon j'arrive après la bataille, mais voici qq petites remarques :
- Pour l'instant ces thèmes-plugin ne fonctionnent qu'avec une 1.9.1
- Oui, un thème (habillage CSS + graphique) est nécessairement fonctionnel pour un jeu de squelettes donné (en l'occurrence ici ceux de la dist 1.9.1)
- On verra + tard comment se préoccuper des comptabilités et du bon rangement de la chose... faisons d'abord collection de nouveaux habits, testons et apprécions pour l'instant, non ? On verra bien quand on croulera sous une avalanche de thèmes (ouais, on peut toujours rêver
Moultes bises,
Romy
Bill a écrit :
Par contre, un plugin gestionnaire de theme, la, je vois deja mieux.
Mais si on regarde bien, on voudra avoir un systeme d'activation, de facon à mettre 12 themes et à choisir (idealement comme preference utilisateur et non ?)
Pareil. Je suis en train de faire un plugin habillage de l'espace privé, et plus j'avance plus je me dis qu'il pourrait gérer les squelettes aussi puisqu'il suffit de cloner le code avec très peu de changements. On aurait une arbo du style :
_plugin_
habillages
-plugin.xml
prive
themes
theme1
theme2
public
themes
theme1 (squelette1)
theme2 (squelette2)
En gros, c'est à mon avis pas encore mature et pas testé jusqu'au bout, ayant pour l'instant que l'arbo suivante concernant un plugin qui ne choisit que l'habillmage de la partie privée du site :
_plugin_
habillages
-plugin.xml
themes
theme1
theme2
Mes deux centimes.
Bonjour ;
Une fois la SPIP 1.9.1 [7339] installée. J’ai créé une Rubrique puis un article.
Si je veux le modifier
J’ai ça : Call to undefined function: traiter_modeles() in on line
Ici
Je ne sais pas si c’est important ou purement cosmetique Chez Firefox, Firebug me dit recherche_desesperement is not defined
?exec=articles_ed… (line 1)
Et Tydy n’aime pas ces lignes (243 244 et 247) et dit
discarding unexpected (dans l’ordre)
<p><div style='text-align:right'><input type='submit' name='Valider' value='Valider' class='fondo'></div></form></tr></table>
<br /></td></tr></table>
<br><br><table width='974' cellpadding='0' cellspacing='0' border='0'>
<tr><td width='974' class='serif'><div style="background-image: url('');"></div><div style="text-align: right; font-family: Verdana; font-size: 8pt"><b>SPIP 1.9.1 [<a href='' target='_blank'>7339</a>]</b> est un logiciel libre distribué <a href='' target='spip_aide' onClick=>sous licence GPL</a>.<br />Pour plus d'informations, voir le site <a href=''></>.</>
</td></tr></table></center></font>
recherche_desesperement is not defined
?exec=articles_ed... (line 1)
Bug connu: http://trac.rezo.net/trac/spip/ticket/559
Et Tydy n'aime pas ces lignes (243 244 et 247) et dit
Ouh là... la compliance de l'espace privé, ça risque d'être un gros chantier
-- Fil
Fil a écrit :
Ouh là... la compliance de l'espace privé, ça risque d'être un gros chantier
-- Fil
echo "</table>\n";
echo "\n<input type='hidden' name='id_auteur' value='$connect_id_auteur' />";
echo "\n<input type='hidden' name='hash' value='" . calculer_action_auteur("valide_plugin") . "'>";
echo "\n<input type='hidden' name='changer_plugin' value='oui'>";
echo "\n<p>";
echo "<div style='text-align:$spip_lang_right'> ";
echo "<input type='submit' name='Valider' value='"._T('bouton_valider')."' class='fondo'></input>";
echo "</div></div>";
# ce bouton est trop laid
# a refaire en javascript, qui ne fasse que "decocher" les cases
# echo "<div style='text-align:$spip_lang_left'>";
# echo "<input type='submit' name='desactive_tous' value='"._T('bouton_desactive_tout')."' class='fondl'>";
# echo "</div>";
#echo "</form></tr></table>\n";
echo "<br />";
Il suffit de démander
* Fil tapotait, le 08/09/2006 12:37:
recherche_desesperement is not defined
?exec=articles_ed... (line 1)Bug connu: http://trac.rezo.net/trac/spip/ticket/559
Et Tydy n'aime pas ces lignes (243 244 et 247) et dit
Ouh là... la compliance de l'espace privé, ça risque d'être un gros chantier
J'en sais quelque chose puisqu'en 1.7, je l'avais faite pour 2 pages :
- les statistiques
- la page des articles (pas le mode édition, l'autre) (le but était de permettre à un rédacteur ayant l'extension HTML validator with Tidy de vérifier dès l'interface privée que son article était valide).
J'avais soumis le patch.
Il s'est perdu dans les limbes de la réorganisation des fichier de la 1.8 puis 1.9.
Actuellement, je vois 2 options pour cette mise en conformité et 2 méthodes de travail :
Les 2 options :
1) passage en interface tout XHTML+CSS sans tableau (autres que pour les données effectivement tabulaire)
2) se contenter de rendre l'interface actuelle W3C compliant (se qui préparerait le 1) au passage, mais par étapes chères à ESJ)
L'option 1) est plus séduisante. Elle a été déjà exprimé à la coding de mars, avec un résultat que l'on connaît : inexistant.
Les 2 méthodes :
1) faire une coding party d'un WE spécifiquement dédiée à ça
2) ouvrir les commits sur le core à une personne qui ne ferait que ça
Ces 2 méthodes répondent à un impératif : ne pas avoir à suivre la SVN en permanence sur une branche parallèle qui serait sur la zone.
Reste une incertitude majeure : maintenant, il y a une branche 1.9 et un trunk.
D'après ce que je vois sur spiip, c'est l'option 1) qui est en train de se mettre en place, mais avec d'abord l'objectif de passer l'admin en AJAX, le XHTML n'étant qu'un passage obligé.
Ceci, AMHA, il serait plus facile de passer en AJAX sur une base W3C compliant (avec un DOM valide donc) partout, et non pas seulement sur les zones AJAXisées.
--
RealET — SPIP fort et vert !
skedus@free.fr a écrit :
Bonjour,
(...)J'ai juste un doute pour une creation avec svn il vaut mieux 'commit' ou
'import' pour le moment je pensais plutot add puis commit (je continue de lire
la doc)
import, c'est pour créer un dépot, or le notre existe déjà
c'est en effet, add pui commit
Si les problèmes persiste, n'hésite pas à poser tes questions sur la liste
Amicalement,
--
James
1) passage en interface tout XHTML+CSS sans tableau (autres que pour les
données effectivement tabulaire)
2) se contenter de rendre l'interface actuelle W3C compliant (se qui
préparerait le 1) au passage, mais par étapes chères à ESJ)L'option 1) est plus séduisante. Elle a été déjà exprimé à la coding de
mars, avec un résultat que l'on connaît : inexistant.
Faux : ça a commencé à se faire, dans le plugin "spiip"
-- Fil