Au temps pour moi... c'est bien ca qu'il faut mettre dans le themeconf.inc.php de l'archive que je t'ai envoyé:
'template_dir' => 'template/yoga'
ATTENTION: il faut extraire l'archive que je t'ai envoyé dans le dossier template/yoga/theme
Et je plussoie flop25... tant que c'est possible de ne pas passer par un nouveau template, alors oui, il faut faire ca en thème.
Hors ligne
@Swan
Effectivement, tant que possible préférer des propositions de thèmes uniquement (Cf. le titre du topic),
et tout faire pour éviter l'usage de templates.
Essentiellement pour des raisons de maintenance, en cas d'évolution de Piwigo comme expliqué.
Swan a écrit:
oO je peux faire les link dans le "themeconf.inc.php"?
Non. Cf. flop25
Mais au besoin tu dois pouvoir faire un @include (attention il doit être au début d'un fichier .css avant tout autre règle).
Je n'en vois pas l'intérêt.
L'ordre actuel des .css est très important et ne devrait pas être modifié. (L'une des rares contraintes pour styler Piwigo).
Si tu as besoin de le modifier, explique pourquoi, et demande comment contourner le problème.
@flop25
flop25 a écrit:
themeconf.inc.php servira (peut-être) pour changer les menubar-xxx.tpl par celui du thème
Je ne sais pas si on a ouvert un feature sur ce point mais oui, il faut le faire. (Cf. Thème Juza. commit, dans les prochains jours).
La règle étant qu'ils seront écrasés par un éventuel template-extension.
Hors ligne
VDigital a écrit:
tant que possible préférer des propositions de thèmes uniquement (Cf. le titre du topic),
et tout faire pour éviter l'usage de templates.
Essentiellement pour des raisons de maintenance, en cas d'évolution de Piwigo comme expliqué.
...
Mais au besoin tu dois pouvoir faire un @include (attention il doit être au début d'un fichier .css avant tout autre règle).
...
L'ordre actuel des .css est très important et ne devrait pas être modifié. (L'une des rares contraintes pour styler Piwigo).
Principes fondamentaux que personnellement (j'imagine que je ne dois pas être la seule) je voudrais voir apparaître clairement dans toute documentation, avant même que l'on me dise copier/coller fichier-truc-muche, etc.
Et dans la présentation PiwigoCamp ad-hoc, bien sûr.
Hors ligne
PiwigoCamp? Oui.
Hors ligne
P@t a écrit:
Il faut par contre modifier le nom des quatres boutons suivants:
Code:
galerie.png => mbCategories.png menu.png => mbMenu.png special.png => mbSpecials.png login.png => mbIdentification.pngEt c'est tout!!! Ca fonctionne....
Donc je met la dénomination pour le "liens.png (mbLinks.png) & pour le tag.png (mbTags.png)" ?
- Petit inconvénient du "prefilter" que tu as fait, je n'est plus le lien de retour sur "accueil" en cliquent sur catégorie :p
- Autres soucis: J'ai activé le plugin Classes de grum 2.0.4 et Avanced Menus Manager pour mettre le menu de lien, j'ai créé un lien en admin... Mais rien sur la page index oO l'image du menu liens, n'apparait pas . Ai je raté une étape ? J'ai purgé les tpl et vidé mon cache navigateur et je suis sous PWG 2.0.7...
Dernière modification par Swan (2010-01-07 23:56:56)
Hors ligne
Swan a écrit:
- Petit inconvénient du "prefilter" que tu as fait, je n'est plus le lien de retour sur "accueil" en cliquent sur catégorie :p
Heu... je sais pas, il faut que je regarde ca...
Swan a écrit:
- Autres soucis: J'ai activé le plugin Classes de grum 2.0.4 et Avanced Menus Manager pour mettre le menu de lien, j'ai créé un lien en admin... Mais rien sur la page index oO l'image du menu liens, n'apparait pas . Ai je raté une étape ? J'ai purgé les tpl et vidé mon cache navigateur et je suis sous PWG 2.0.7...
C'est pas normal non plus... je regarderai ca aussi...
Hors ligne
P@t, Est ce que tu as regarder le soucis avec le KoffeeTux? chose interressante, sous IE8 les icones (images) liens, images alléatoires, etc... les images sont absentes.
Sinon chose simple, je le met en non compatibilité avec AMM sur la dernière révision -_-?
Hors ligne
Swan je n'ai pas regardé dans le détail mais:
- AMM est souvant utilisé
- Il ajoute des menus dans menubar (Image aléatoire, liens, menus personnalisés,...)
- Il intègre et gère les menus ajoutés par d'autres plugins (Additional pages,...)
Tu ne pourras pas l'igorer totalement.
Je te propose d'imaginer un icone par défaut pour les menus non standards.
That's it.
Hors ligne
Swan, peux-tu m'envoyer par mail le theme (la où tu en es...)
J'y jetterai un oeil....
Sinon, entièrement d'accord avec VDigital, il faut prévoir une icone par défaut pour AMM, Additional Pages, etc...
Il faudra également modifier le préfiltre pour prendre cet icone en compte...
Hors ligne
P@t, ayant lu ton message hier, je te réponds maintenant, car mon activité ce soir sur Piwigo va être à la réinstallation des révisions sur le site des extensions avec les trois templates modifié en thèmes mis sous UN seul et unique tempate le Csn. Donc tu vas pouvoir le testé dès que j'aurais mis à jour :)
Hors ligne
Bonsoir,
Swan, j'étais en train de te créer ton espace sur le dépôt SVN pour [extension by Swan] Csn, quand ddtddt m'a demandé de vérifier l'écart entre le template Csn et le template yoga. Bilan, les fichiers modifiés sont:
content.css
default-colors.css
default-layout.css
menubar.css
menubar_categories.tpl => ajout d'un <br />
search.tpl => le bouton reset utilise maintenant la class CSS "reset" et non plus "submit"
et plein d'icones.
Donc, est-ce bien raisonnable d'avoir un template (lourd à maintenir) alors qu'il n'y a que des CSS et des icones qui sont touchés ?
En fait j'étais en train de me prendre la tête pour savoir comment on peut proprement avoir 1 template (incluant N thèmes) dans SVN et simultanément 1 template et N thèmes sur piwigo.org/ext (le gestionnaire d'extensions).
Avoir N thèmes dans le gestionnaire d'extensions, c'est beaucoup mieux que d'avoir un unique "lot", mais je voudrais faire ça proprement. Si on pouvait avoir dans SVN un extensions/yoga/theme1 (auteur Swan), extensions/yoga/theme2 (auteur Swan) et extensions/yoga/theme3 (auteur Grum), ce serait mieux.
Tiens ça me fait penser à flop25 qui a la même problématique. Je vais lui demander son avis.
Hors ligne
plg a écrit:
content.css
default-colors.css
default-layout.css
menubar.css
menubar_categories.tpl => ajout d'un <br />
search.tpl => le bouton reset utilise maintenant la class CSS "reset" et non plus "submit"
et plein d'icones.
content.css
default-colors.css
default-layout.css
menubar.css
=> Toutes tes modifs peuvent être dans un ./template/yoga/theme/xxxxxx/csn-common.css
ou tout simplement dans tes ./template/yoga/theme/xxxxxx/theme.css
menubar_categories.tpl => ajout d'un <br /> cela devrait pouvoir se régler en css.
search.tpl => le bouton reset utilise maintenant la class CSS "reset" et non plus "submit"
#theSearchPage input[type="reset"] { }
les icones... cf. themeconf.inc.php
D'ailleurs, on devrait pouvoir proposer des jeux d'icones séparément... Il faudra ouvrir un topic pour gérer ça indépendamment du reste si possible. Les créateurs d'icones se régaleraient.
;-)
Hors ligne
me vla pour donner mon exemple et mon avis sur la forme :
Dans mon cas c'est plus simple : le template floPure a des pack de thème mais sur SVN j'ai tout le dossier du template avec tous les thèmes en un seul dossier extension. Mon seul pack pour yoga n'est pas sur SVN (bou je sais ce n'est pas bien) mais néanmoins, si je devais le mettre sur svn je ferais ainsi (et cela vaut pour mon avis dans ton cas ) => Dans le cas où les thèmes ont une dominante commune, je les sortirais en pack (regroupé en une extension dans le gestionnaire et dans SVN)
Dans ton cas, tu vas - semble-t-il - supprimer ton template et passer tes thèmes sous le template Yoga : dans cette optique, tu as des déclinaisons de couleurs que je te suggérerais de regrouper en un pack dans le gestionnaire. Les autres tel koffetux qui sont particuliers les laisser en 'unique' extension. Pour te faciliter la tache sur le SVN tu peux regouper tous tes thèmes en un dossier Swan_theme_yoga
Par contre si ton template reste, je te suggère de mettre qq thèmes 'par défaut' avec ton template et à coté de sortir des pack de thèmes. L'avantage c'est que si tu modifies ton template et que cela à des répercussions sur les thèmes, tu n'a pas une vingtaine d'extensions à mettre à jour d'un coup mais seulement 2-3 pack ^^
Hors ligne
Je recommande plutôt d'avoir 1 extension par thème. C'est un petit peu plus de travail pour l'auteur de l'extension, mais les avantages sont:
* les thèmes sont beaucoup plus visibles
* on peut voir la popularité de chaque thème (nombre de téléchargement)
* ça -//:---\spam mieux l'activité
Le fait de regrouper dans un seul répertoire SVN n'est pas contradictoire.
Hors ligne
plg a écrit:
Je recommande plutôt d'avoir 1 extension par thème. C'est un petit peu plus de travail pour l'auteur de l'extension, mais les avantages sont:
* les thèmes sont beaucoup plus visibles
* on peut voir la popularité de chaque thème (nombre de téléchargement)
* ça -//:---\spam mieux l'activité
Le fait de regrouper dans un seul répertoire SVN n'est pas contradictoire.
oui ce n'est pas incompatible mais concernant les déclinaisons de couleurs ça ne sert vraiment à rien de les publier individuellement dans le gestionnaire car il n'y a que la couleur qui change ! La popularité ne montrera que la popularité d'une certaine couleur et quant à l'activité, elle se voit au nbr de révisions et chaque nouvelle révision refait apparaitre le theme en top dès l'accueil du gestionnaires
ex http://fr.piwigo.org/ext/extension_view.php?eid=158 => seul un détail change donc un pack
http://fr.piwigo.org/ext/extension_view.php?eid=233 => celui là par contre aurait largement pu etre scindé en 2 mais ça c'est de la fainéantise j'en convient
après c'est au feeling de chacun et sa manière de travailler
Hors ligne