plutôt que de répondre en privé à P@t et à plg sur un échange que l'on a commencé par émail, je poste ici çà profitera à tout le monde.
une âme charitable se chargera j'espère, d'en extraire ce qui est important pour éventuellement le résumer sur le topic dédié du forum public anglais.

============================================================================================================>
j'ai fini de migrer mes thèmes sous la nouvelle structure.
çà c'est avéré un chouilla plus compliqué que je ne le pensais, mais j'y suis arrivé.


par contre, faut avoir en tête que je suis tétu et que comme la fonctionnalité de "parent" est mise à disposition, j'ai décidé de l'utiliser et donc créé mon propre thème "parent" => 'gally-default'
tous mes thèmes (gally-grum-dark-II, gally-graphite, gally-lapis-lazuli) sont donc dérivés de ce thème 'gally-default'

'gally-default' fournit tous les templates, les css et autres trucs communs à tous les thèmes
* ce thème pointe en dur sur le JS de 'default' pour obtenir jQuery. Sur ce point, je ne suis pas satisfait et je prévois le bordel si quelqu'un décide d'inclure dans son propre thème un autre framework, mais bon je ne me battrais pas sur ce sujet...
* chaque thème à ses propres fichiers .css, icones et fichiers de configuration .conf
* le thème 'gally-default' apparait dans la liste des thèmes, le résultat est est vraiment moche et je ne souhaite pas développer un thème pour le thème par défaut, selon la même logique que celle en place pour le thème 'default'
* pour profiter d'un thème 'gally-quelque-chose' il faudra disposer obligatoirement du thème parent 'gally-default'


Je pourrais faire le choix de faire des thèmes complètements autonomes : inclure systématiquement dans chacun des thèmes tous les fichiers .css, .tpl et autres. mais çà ne me convient pas non plus : en terme de maintenance, çà va être c****t à gérer :
- faire un thème
- copier/coller partout voir si fonctionne comme il faut avec tous les autres thèmes
- voir que çà ne fonctionne pas
- corriger
- refaire des copier/coller si fonctionne comme il faut avec tous les autres thèmes
- ....
De plus, je ne vois pas l'intérêt d'avoir 3 fois les mêmes fichiers .tpl sur le serveur alors que le système me permet de ne les avoir qu'une seule fois.



Donc en résumé :
- pas de problème pour la nouvelle architecture qui permet effectivement de réduire un thème à quelques fichiers tout simples à gérer
- prévoir que le thème 'default' ne sera pas forcément le seul à être un thème parent et que dans cette situation, les thèmes de ce type ne doivent pas être visibles ni pour l'admin, ni pour l'utilisateur (une propriété genre 'isParent = true' permettrait de les filtrer)
- prévoir dans le thème manager que lorsque l'on installe un thème, le thème parent soit installé automatiquement s'il n'est pas installé

Attention, une petite sécurité à prévoir peut-être : j'ai mis pour voir sur mon thème 'gally-default' le thème 'gally-default' (donc lui même) en tant que parent => provoque une erreur 500 sur le serveur


Sinon, j'ai quand même un bug dont je ne comprends pas l'origine :
- je suis sur le thème sylvia
- je vais dans 'personnaliser' mettre le thème "gally-quelque-chose"
- je valide, le thème est bien appliqué
- je retourne dans 'personnaliser' mettre n'importe quoi d'autre comme thème ('clear', 'dark, 'gally-autre-chose')
- je valide, le thème 'Sylvia' est systématiquement appliqué

une idée ?



question complémentaire : comment submiter dans les extensions, les thèmes mis à jour avec la 2.1 avec la nouvelle architecture ?
ne serait-il pas temps d'avoir dans le dépôt :
- extensions/plugins
- extensions/thèmes

échanges de mails a écrit:

P@t a écrit :
>
>
> Le 15 mars 2010 22:09, Gwendal <gwendalb@free.fr> a écrit :
>
>     bon, j'ai commencé à regarder.
>
>     pour l'instant je n'ai pas réussi à migrer le premier thème de gally : je pense que c'est plus lié à des évolutions sur les templates de la 2.1 qu'au changement de l'architecture (tout un tas de variables utilisées dans les templates n'existent plus...)
>
>
> Oui, il y a eut quelques évolutions, notamment la gestion de l'affichage des catégories qui ne se fait plus en php, mais directement en tpl (menubar_categories.tpl).
> Il doit y en avoir d'autres, je n'ai pas tout en tete.
>
>
>     pour les modifs sur le header.tpl, y a en un certain nombre, c'est pas la mort, mais n'ayant pas pu valider mon premier themes, je ne suis pas en mesure de m'exprimer vraiment.
>
>
> Pour le header.tpl, c'est pas bien méchant, en effet... C'est surtout la boucle qui affiche les local_head et les theme.css
>
>
>     quelques remarques en vrac :
>
>     * le theme_conf.inc.php
>     j'aimerais avoir çà :
>     $themeconf = array(
>       'theme_name' => 'Gally/Grum Dark II',
>       'theme' => 'grum-dark-II',
>       'parent' => 'default',
>       'icon_dir' => 'themes/grum-dark-II/icon',
>       'mime_icon_dir' => 'themes/grum-dark-II/icon/mimetypes/',
>     );
>
>     avec la donnée "theme_name" exploitée dans la liste déroulante du choix du thème ==> çà permettrait un peu plus de liberté dans le nom du thème (espaces et autres caractères aujourd'hui non autorisés), et çà permettrait aux personnes créant des thèmes de les regrouper (je pense à mes thèmes qui tournent autour de 'gally', ou tous les thèmes 'flo' pour ne pas penser qu'à moi...)
>
>
>  On en discute avec Pierrick, et à priori, on se tourne vers la meme gestion que le main.inc.php des plugins (Nom du thème, URL, etc... en commentaire au début du fichier themeconf).
> Il y aura également une table "themes" avec toutes ses données enregistrées.
>
> 
>
>     * le répertoire 'JS'
>     je ne suis pas certain que c'est une bonne idée que de mettre le JS dans le theme.
>     c'est la porte ouverte à tout et n'importe quoi...
>     je fais un thème, je met autre chose que jQuery, ou une version autre de jQuery ==> résultat difficile à maîtriser pour les plugins par exemple (P@t, on en a éjà fait l'expérience...)
>     pour ma part, j'ai déjà mis des trucs du genre :
>       {known_script id="jquery" src=$ROOT_URL|cat:"themes/"|cat:$themeconf.parent|cat:"/js/jquery.packed.js"}
>       {known_script id="jquery.ui" src=$ROOT_URL|cat:"themes/"|cat:$themeconf.parent|cat:"/js/ui/ui.core.packed.js"}
>       {known_script id="jquery.ui.tabs" src=$ROOT_URL|cat:"themes/"|cat:$themeconf.parent|cat:"/js/ui/ui.tabs.packed.js"}
>       {known_script id="jquery.ui.dialog" src=$ROOT_URL|cat:"themes/"|cat:$themeconf.parent|cat:"/js/ui/ui.dialog.packed.js"}
>     çà ne me plait pas trop : je suis dépendant du parent... donc forcément, tous mes thèmes auront comme parent 'default' car il est hors de question pour moi de livrer jQuery avec mes thèmes : je pars du principe que c'est à Piwigo de fournir et maintenir à jour ce framework (et çà fait quand même 1Mo !)
>
>
> Tu n'es pas obligé d'avoir le thème default comme parent pour utiliser les js de default.
> Le theme default n'est pas censé etre supprimé, il sera toujours la... donc tu peux coder sans problème directement themes/default/js/jquery.packed.js
> Et rien ne t'empeche de rajouter un repertoire js à ton theme pour avoir tes propres fichiers js.
>
>
>
>     à moins d'avoir dans le theme_conf, un répertoire 'js_dir' que j'exploiterais tout seul comme un grand :
>       {known_script id="jquery" src=$ROOT_URL|cat:$themeconf.js_dir|cat:"/jquery.packed.js"}
>     c'est une solution de contournement, mais bon. je préfererais quand même garder un répertoire dédié à ce genre de chose.
>     "template-extension/jQuery' ?
>
>
> js_dir, c'est ce que j'avais prévu au départ... mais franchement, en y réfléchissant bien, ca n'a aucun intéret.
> Et si tu veux parler de template-common, on en veut plus! Le theme default fait office un peu de template-common.
>
> 
>
>     * thème 'defaut'
>     le thème default n'apparait pas dans la liste de thèmes disponible.
>     par quelle magie ?
>
>
> Le thème default est filtré dans la fonction get_pwg_themes.
> Pierrick voulait fusionner clear et default, mais ce n'est pas très logique sur certains points (vu que le theme par défaut est Sylvia, ca risque de porter à confusion)
>
> 
>
>     - si je fais un thème "X" dont le parent est le thème "Y", mais que je ne veux pas que le thème "Y" soit disponible ?
>     (pour ma part aujourd'hui je supprime tous les thèmes et ne laisse pas le choix aux visiteurs)
>
>
> Pierrick est en train de coder le thème manager (identique au plugin manager) qui permettra d'activer et désactiver les thèmes dans le panneau d'admin.
>
>
>     ps: vous comprendrez au travers de cette réponse par mail, que j'ai une grande flemme pour tout traduire en anglais et poster sur le forum (pas le temps et pas le courage)
>
>
> Je te comprend très bien!
> Pierrick fera un petit résumé sur le forum EN...