[spip-dev] SPIP 3.1 : thèmes pour la dist

Dev
1

je renvoie le mail complet, désolé !

Hello,

Deuxième proposition d’ajout pour la version SPIP 3.1.

Ajouter une gestion simple de thèmes pour la nouvelle dist qui sera proposée.

Un consensus s’est dégagé pour proposer une dist “nue” simple et dépouillée. D’aucun, comme moi, dirait “trop” dépouillée.

Erational a donc proposé un thème pour coincider avec mes remarques.

De fait, il parait intéressant de faire un pas de plus et de proposer des thèmes dist et une gestion de ces thèmes intégrés à la distribution SPIP 3.1.

L’idée est la suivante :

  • partir la notion de thème déjà utilisé par certains squelettes comme zpip, spipr ou sarka-spip mais en limitant la personnalisation à du css.

  • par cohérence avec plugins-dist/ et squelettes-dist/, SPIP installerais un répertoire themes-dist/ incluant l’ensemble des thèmes élaborés pour la dist.

  • utiliser Zen-Garden pour choisir son thème (quelques adaptations sont nécessaires mais paraissent mineures). Zen-Garden prendrait donc place aussi dans la distribution SPIP 3.1.

Questions:

  • ça convient à la plupart ?

  • on y go ?

2

Question : réfléchir à "c'est la porte ouverte à quoi ?", ça implique quoi ensuite à court/moyen terme ?

Si les gens installent un squelette qui ne gère pas les thèmes (et qui ne déclare rien à ce propos), Zen Garden est-il toujours actif ? visible ? montre-t-il toujours une liste de thème à activer ? insère-t-il toujours ces CSS activés précédemment ?
Et si on modifie soi-même les squelettes dans son dossier squelettes/ et que ça n'a plus rien à voir avec la dist ?

Il faut que tout reste cohérent et pas bordélique au-delà de l'installation première, une fois que ça vit.

3

Hello !

Questions:
- ça convient à la plupart ?
- on y go ?

Question : réfléchir à "c'est la porte ouverte à quoi ?", ça implique quoi ensuite à court/moyen terme ?

Distribuer des thèmes avec SPIP est une discussion qui a déjà eu lieu à la SPIP Design Party (DiPi) de Nantes, en 2007.

Parmi les pistes évoquées, celle qui me semblait la plus intéressante (et qui est ré-évoquée dernièrement, si j'ai bien suivi les différentes discussions de cette liste) est celle qui consiste a distribuer un squelette (dist) avec une structure HTML assez standard et 3 à 5 thèmes CSS interchangeables, sans forcément de mécanisme de sélection de ceux-ci.

C'est dans cette direction que j'ai orienté mon travail depuis. Ça me semble toujours être la bonne approche, d'une part parce qu'elle ne réclame pas un trop gros effort de fabrication/maintenance côté dev et d'autre par parce qu'elle reste simple à appréhender/documenter, donc à comprendre, côté Gus.

Quelques rappels :

- Un thème est l'habillage graphique d'un site. Concrètement, il est constitué de déclarations CSS qui s'appliquent à une structure HTML donnée, laquelle n'est pas interchangeable (et je ne parle pas encore de squelette SPIP).
- Dans une logique de distribution de thèmes, supposée extensible (ie. je dois pouvoir ajouter mon thème) ceux-ci doivent être rangés dans des sous-répertoires, car il peuvent convoquer des fichiers tiers (images, fontes, etc.).
- Enfin, pour éviter la duplication de code, toujours dans une logique de distribution, chaque thème s'appuie sur une base CSS commune.

C'est ce constat de multi-dépendance que nous avions fait à la Dipi : un thème dépend de la base CSS, de la structure HTML et du squelette. Si vous envisagez de gérer ces compatibilités-là, au niveau de SPIP (via plugins, fichiers paquet.xml et/ou panneau de conf), je vous souhaite bon courage ! De mon point de vue, ce n'est tout simplement pas nécessaire :
- c'est mettre la charrue avant les bœufs : inutile de prévoir un système de gestion de thèmes… qui n'existent pas encore ! Tel système s'envisage pour faciliter une manipulation trop laborieuse en raison de sa fréquence et/ou du nombre (de thèmes), ce qui est loin d'être le cas :wink:
- Enfin, cela ne répond pas au besoin d'usage, qui est d'aider l'utilisateur à se choisir un thème (il ne va pas en changer tous les 4 matins => inutile de systématiser). Une bonne documentation, explicite et friendly, devrait suffire.

Commençons par le début, c'est-à-dire par faire exister ces thèmes… En dispose-t-on ? Parmi ceux-ci, peut-on en sélectionner 3 qui soient bien sympas ? suffisamment sympas, complets et pour être distribuables ? Sinon, ce n'est pas la peine de prévoir cela pour la prochaine version de SPIP :wink:

Donc, en attendant et consécutivement, quel écosystème propose-t-on pour les thèmes, c'est-à-dire quelle structure HTML standard, quelle dist et quelle logique d'organisation CSS ? Ça, ça tombe bien, ce sont les questions que j'ai explorées, testé et développé ces dernières années. Voici la doc disponible, pour mémoire :

http://romy.tetue.net/structure-html-de-base
http://romy.tetue.net/un-deux-trois-feuilles-css
http://romy.tetue.net/ordre-styles-CSS-SPIP
et http://daisy.tetue.net

-- tetue

4

Effectivement. Je suis absolument totalement d'accord avec ces deux points.

Aussi bien pour moi en tant qu'intégrateur pro, que pour les quelques personnes de mon entourage qui voulait un site perso rapide, je n'ai jamais compris l'intérêt d'un sélecteur de thème *à l'intérieur de son site à soi*.

Ce type de sélecteur peut éventuellement avoir un intérêt publiquement sur un site de démo pour voir rapidement plusieurs thèmes appliqués à un site réel, et ainsi aider à en choisir un. Mais du coup ça serait propre à un site démo de la "dist", propre à un site démo de "SpipR", propre à un site de démo de "Sarkaspip", etc.

Dans le site d'une personne ou d'une assoc, pas besoin de machinerie compliquée comme ça. Et encore moins par défaut.

5

Soyons plus précis encore et distinguons deux besoins *différents* :

1) Lister des thèmes existants pour un type de squelettes donné et pouvoir apercevoir leur aspect graphique rapidement.

2) Installer facilement un thème dans son site.

Ces deux points peuvent être améliorés par rapport à la situation actuelle, mais pas mélangés. Ce sont deux besoins différents.

Voir des thèmes, ça peut se faire sur un site de démonstration commun propre au type de squelettes en question (un site de démo de "dist", un site de démo de "spipr", etc).

Installer un thème facilement, il suffit qu'il soit empaqueté sous forme de plugin (un dossier, un paquet.xml). Et il peut alors s'installer en UN CLIC, sans FTP, donc pas de mauvaise foi sur ce sujet s'il vous plaît.

6

​Il y aurait peut être un intérêt à faire évoluer la présentation de
http://plugins.spip.net/spip.php?page=plugins&categorie=theme afin de
pouvoir clairement identifier les thèmes pour la dist, ceux de Zpip, ceux
de sarka etc.

Certes, c'est visible dans le champs "Compatible" dans la description mais
pas des plus ergonomiques.

Joseph

7

(désolé si c'est un doublon, problème avec thunderbird)

Bonjour,

C'est chouette de voir toute cette émulation autour de la nouvelle dist.
Pourrait-on résumer rapidement et concrètement comment faire des propositions de thèmes pour la dist, pour les gens intéressés ? Pour l'instant, c'est encore un peu flou, à moins de recouper les éléments de réponse éparpillés dans plusieurs fils de discussion.

S'agit-il d'une unique feuille CSS, ou peut-on inclure d'autres fichiers : polices de caractère, images ?
Si on peut avoir plusieurs fichiers, quelle est la nomenclature, s'agit-il d'un plugin, ou d'un simple zip ?

Il y a bien l'exemple du thème «tonton» ici : http://zone.spip.org/trac/spip-zone/browser/themes/dist/v1/tonton/
Mais ça ne répond pas à toutes les questions.

8

Sur le principe ça me plait bien, à une nuance près : pourquoi "en limitant la personnalisation à du css" ?
Un thème pour la dist pourrait contenir une image (c'est déjà le cas), une webfont ou autre ressource.
Le but est de rester léger, un thème dist devrait être un peu pédagogique, en tout cas être facile à prendre en main / modifier / bidouiller, mais pourquoi se limiter à la pure css ?

Sur le fait d'avoir un site de démo en plus (idée de Rasta/tetue), je suis partagé.
Zengarden permet de tester directement les thèmes sur son propre contenu, avec ses rubriques et son menu, ses titres, c'est plus réaliste que sur un site de démo avec du faux texte.

Par contre, comment serait distribué l'ensemble ?

S'il faut chercher dans SVP et installer zengarden, puis les thèmes dist, beaucoup de "débutants" risquent de passer à côté, alors que ça leur est plutôt destiné, justement.
SVP ne peut pas (il me semble) lister uniquement les thèmes compatibles avec le squelette installé et activé.

9

Yo !

Dans le site d'une personne ou d'une assoc, pas besoin de machinerie
compliquée comme ça. Et encore moins par défaut.

Soyons plus précis encore et distinguons deux besoins *différents* :

1) Lister des thèmes existants pour un type de squelettes donné et pouvoir apercevoir leur aspect graphique rapidement.

2) Installer facilement un thème dans son site.

Ces deux points peuvent être améliorés par rapport à la situation actuelle, mais pas mélangés. Ce sont deux besoins différents.

Voir des thèmes, ça peut se faire sur un site de démonstration commun propre au type de squelettes en question (un site de démo de "dist", un site de démo de "spipr", etc).

Installer un thème facilement, il suffit qu'il soit empaqueté sous forme de plugin (un dossier, un paquet.xml). Et il peut alors s'installer en UN CLIC, sans FTP, donc pas de mauvaise foi sur ce sujet s'il vous plaît.

Suite aux échanges IRC d'hier, où j'ai détaillé ces besoins, je reporte ici :

== Besoins du Gus (dans l'ordre) :

1) savoir que des thèmes existent
2) les voir, pour voir si ça lui fait envie
3) savoir comment essayer/installer
4) essayer sur son site
5) adopter un thème

== Comment y répondre ?

Seuls 4 et 5 nécessitent d'être dans SPIP.
Ce n'est pas le cas de 1, 2 et 3, qui seraient même préférables publiquement.

1) savoir que des thèmes existent => communication publique (sur spip.net ?)
2) les voir, pour voir si ça lui fait envie => galerie &/ou switcher (sur site de démo… dist.spip.net ?)
3) savoir comment essayer/installer => explication en ligne
4) essayer sur son site => download via plugin, si le thème est structuré en plugin, ou à l'ancienne via FTP
5) adopter un thème => bin, c'est fait :slight_smile:

== Que faire ?

Rien pour 4 et 5 :
La mécanique de distribution existe déjà : les plugins SPIP. En plus, pour les compatibilités, chaque thème, packagé en plugin, indique au besoin quel squelette est prérequis. Et hop !

Reste donc 1, 2, 3 : c'est à-dire communiquer sur les thèmes. Ça peut se faire via une page de démo avec switcher de thème, comme suggérait Rasta, sur plugins.spip.net ou ailleurs.

-- tetue

10

Bonjour Romy

Pour un nouveau site de co-working, j'installe un SVN [21769]
(pour -enfin- tester la sauvegarde prefix ! )

N.B. mais attention aux modifications sur la BDD ;
pourrait-on revenir facilement en 3.0.17 sur les memes tables ??

A première vue, certaines polices privées me semblent un peu plus "heurtées" que la douce interface traditionnelle...

Je regrette de n'avoir pas suivi IRC hier (il existe un archivage ?).
Bravo pour ce résumé

Déja, pour 4 (et 3 ),
rajouter un compagnon Webmestre avertissant/introduisant
  la mécanique des thèmes (qui reste LOIN d'etre evidente)...

YannX

PS je vois apparaitre fugitivement des paves 3erreurs (en rouge)
lors de la première installation de plugins par SVP ! ???
(juste Crayons et Skeleditor pour commencer / bientot dump… )
- egalement un message popup mal cadré au survol des plugins-dist
(et qui reste rémanent si on a ouvert le plugin) : c'est pas un peu violent ?

11

La je ne suis pas convaincu.
Je pense qu'on peut faire mieux en distinguant quelque peu l'interface SVP
pour les squelettes/modules et celles pour les thèmes, ne serait-ce que
pour gérer la compatibilité thème / squelette.

Alors le faire aujourd'hui ou plus tard (dans 2 à 3 ans) c'est une bonne
question.

A ce propos, il faut peut-être envisager pour l'avenir d'introduire des
nouveaux concepts pas forcément figés et ficelés en acceptant les
potentielles incompatibilités futures. Ça nous permettrait d'avoir un
développement plus dynamique.

12

Ça me semble très indiqué, pour le moins,
pour mieux mettre en valeur les thèmes et leurs spécificités
et aussi pour désencombrer les listes présentées :
besoin très clair dans l'interface privée de spip (liste des plugins non installés)
mais qui doit aussi se manifester lors d'une recherche sur plugins.spip .

JLuc

13

+1 (compagnon spécifique thème et "filtrage" apparent )

Je viens de monter/montrer un SPIP-svn comme cahier coopératif à un ingénieur ;
il m'a fait une remarque -de confort, mais pas que- sur l'interface privée (sur Mac)
les boutons "Enregistrer" sont à peine visible sur le fond sous-jacent,
et la longueur des formulaires de saisies empeche de les apercevoir !!
     Idée: ne pourrait-on imaginer (au moins pour les formulaires principaux non ajaxisés)
              de "remonter" le bouton d'enregistrement en colonne droite ?
Autre difficulté : l'apparence de la page exec=rubrique lui rendait difficile
de voir les boutons "creer un article" (et deja de comprendre la différentiation article-rubrique)
    Idée : si la taille du textarea#TEXTE pouvait être minimisée a quelques lignes sur Rubriques,
sans doute que cela faciliterait la prise en main...

@+

14

Bonjour à tou·te·s !

Attention à bien ranger chaque thème dans un sous-répertoire !

Pourrait-on résumer rapidement et concrètement comment faire des propositions de thèmes pour la dist, pour les gens intéressés ? Pour l'instant, c'est encore un peu flou, à moins de recouper les éléments de réponse éparpillés dans plusieurs fils de discussion.

S'agit-il d'une unique feuille CSS, ou peut-on inclure d'autres fichiers : polices de caractère, images ?

Un thème est constitué d'au moins une feuille de style, « theme.css », laquelle peut appeler d’autres fichiers : images, polices, etc. Un thème est donc nécessairement rangé dans un répertoire, simplement nommé « /theme ».

Il s'applique par cet appel dans le head, après la base :
<link rel="stylesheet" href="/theme/css/theme.css">

Ça ne semble pas être le cas actuellement dans la dist où il faudrait pourtant donner le bon exemple !

S'il n'est pas rangé dans un sous-répertoire, il n'est pas facilement débranchable ni interchangeable : on n'est donc plus dans la notion de thème, mais juste dans la personnalisation CSS… laquelle se fait via perso.css : du coup, comment comprendre ?

Pour rappel (et pour répondre à la question initiale de tcharlss) :
http://romy.tetue.net/858

Si on peut avoir plusieurs fichiers, quelle est la nomenclature, s'agit-il d'un plugin, ou d'un simple zip ?

Dans SPIP :

- cela peut aussi être un simple répertoire, puisque c'est ainsi que ça marche en statique, éventuellement zipé
- chaque répertoire thème peut, en plus, contenir un fichier paquet.xml, qui permet de le distribuer sous forme de plugin.

Bref, comme chacun·e préférera :slight_smile:

-- tetue

15

S'il n'est pas rangé dans un sous-répertoire, il n'est pas facilement débranchable ni interchangeable : on n'est donc plus dans la notion de thème, mais juste dans la personnalisation CSS… laquelle se fait via perso.css : du coup, comment comprendre ?

Ben disons qu'on est dans SPIP. Donc ya la notion de #CHEMIN. Donc de "path" (tous les chemins relatifs possibles, et un choisi en priorité).

Donc de fait, SANS mettre "theme/" dans le HREF, on peut bien *surcharger* le thème entier, puisque c'est #CHEMIN qui est utilisé.

#CHEMIN{css/theme.css}

Le thème "par défaut" est fourni dans la dist, et les thèmes supplémentaire ont bien cette organisation :
/mon_theme/
     paquet.xml
     css/…
     images/…

Avec donc des dossiers supplémentaires possibles (images, etc).

16

Yep,

S'il n'est pas rangé dans un sous-répertoire, il n'est pas facilement débranchable ni interchangeable : on n'est donc plus dans la notion de thème, mais juste dans la personnalisation CSS… laquelle se fait via perso.css : du coup, comment comprendre ?

Ben disons qu'on est dans SPIP. Donc ya la notion de #CHEMIN. Donc de "path" (tous les chemins relatifs possibles, et un choisi en priorité).

Donc de fait, SANS mettre "theme/" dans le HREF, on peut bien *surcharger* le thème entier, puisque c'est #CHEMIN qui est utilisé.

#CHEMIN{css/theme.css}

Pas très bien compris…

Le thème "par défaut" est fourni dans la dist, et les thèmes supplémentaire ont bien cette organisation :
/mon_theme/
   paquet.xml
   css/…
   images/…

Il faudrait donc homogénéiser, que ce soit pareil partout (dans la dist comme pour tout autre thème), ne serait-ce que par pédagogie : ne montrer qu'une seule façon de faire, celle la plus attendue, au lieu de dérouter/complexifier en maintenant des différences.

-- tetue

17

Bonjour,

Ce distinguo pas évident entre rubrique et articles pour les débutants se retrouve depuis des lustres avec SPIP.
Ne serait-il pas concevable d'associer distinctement une icône de type "répertoire" aux rubriques et une distincte de type "fichier texte" aux articles (je veux dire formellement et non pas toutes deux encadrées de la même manière) ?
Ceci permettrait alors d'éventuellement juxtaposer les items en proposant systématiquement l'article en premier choix, et la rubrique en dernier.
???

Bonne continuation.

Philippe