From : ARNO*
Subject : Perspectives 1.9
Newsgroups : gmane.comp.web.spip.devel
Date : 2005-04-20 17:22:03 GMT

Salut,

Histoire de commencer les travaux sur la prochaine version de SPIP, voici quelques notes...

(1) Vers une version 1.9

D’abord, il s’agirait de travailler sur une version 1.9, et non une version 2.0. Je m’explique : ce qu’on nomme la version « 2.0 » de SPIP, c’est une version qui à la fois reposerait sur le nouveau moteur de squelettes (déjà intégré dans la 1.8), mais qui de plus offrirait les outils graphiques et ergonomiques pour l’exploiter (c’est la raison pour laquelle, finalement, la version 1.8 est sortie sous cette appellation).

Il s’agirait donc de poursuivre encore un moment sur la série 1.x, qui repose sur le principe d’une base fixe (on livre une structure de base de donnée fixe aux utilisateurs, ce qui nous permet d’avoir une interface de gestion très cohérente) avant de passer à la 2.0. Il nous semble en effet que ça vaut le coup, pour terminer sur une belle version, qui pourra tenir pendant tout le développement de la 2.0 (qui, elle, risque d’être relativement longue).

(2) Vers des squelettes faciles à installer

Une des idées est de permettre l’installation de dossiers de squelettes de façon extrêmement facile. Avec la 1.8, on n’en est vraiment pas loin (spip_path), mais ça n’est pas complet et absolument pas « évident » pour un débutant.

L’idée serait (en gros), de pouvoir installer des sous-dossiers dans le dossier /squelettes. Chacun de ces dossiers contiendrait donc, c’est le but, des squelettes complets. Sur le principe des dossiers de thèmes des nukelike. De plus, via une page de configuration de l’interface privée, on pourrait configurer l’accès à ces squelettes (ce qui revient à paramétrer le spip_path de la 1.8, mais via une interface graphique).

Voici quelques notes pour discussion :

(a) Le dossier « squelettes » serait destiné à accueillir des dossiers complets, c’est-à-dire qu’on aura, par exemple : * /dist (squelettes par défaut, à la rigueur pas besoin de trop changer) ; * /squelette (le squelette perso, pour compatibilité avec la 1.8) ; * /squelettes/graphique /squelettes/nukelike /squelettes/animations ...

 de cette façon, on peut proposer une page de configuration qui permettra de modifier le spip_path via l’interface graphique ; le truc pourrait par exemple proposer :

« Utiliser, dans l’ordre : * squelettes situés à la racine du site : [oui/non] (ancienne méthode de SPIP) * squelettes personnels installés dans le dossier « squelette » : [oui/non] (méthode SPIP 1.8) * l’un des squelettes suivants (dossier /squelettes) : * graphique * nukelike * animations... * le squelette par défaut /dist. (en fait, cette option ne se décoche pas) »

On a deux avantages :
 d’abord, sans modification de son installation (possiblement ancienne), on peut tester/utiliser les nouveaux squelettes, et éventuellement revenir à une ancienne méthode ; le truc, c’est tout simplement que ça fabrique le spip_path automatiquement ;
 ensuite, cela permet de lister automatiquement le contenu du dossier « squelettes » pour afficher les différents squelettes (entiers, façon plug-ins) et le proposer ; on peut même définir un nommage de fichiers permettant de récupérer, à cet endroit, une copie d’écran et un descriptif (par exemple : « ce squelette très graphique n’est pas conseillé pour les sites ne disposant pas des fonctions de redimensionnement des images »).

(b) il serait pratique de pouvoir définir un fichier « mes_fonctions » dans les dossiers de « squelette », de façon à pouvoir, notamment, définir un certain nombre de variables (par exemple, les fonctions de texte graphique utiliseraient avantageusement la possibilité d’utiliser des variables communes).

(c) un raccourci #DOSSIER_SQUELETTE, qui permettrait d’insérer dans le squelette un chemin vers le dossier du squelette ; ceci permettrait d’appeler un fichier de css lié au squelette : par exemple, dans /dist, il serait bon de placer les fichiers « typographie.css », « habillage.css » et « impression.css » (parce qu’ils dépendent directement du squelette en question, avec une utilisation spécifique de classes et identifiants), alors que « spip_style.css » resterait à la racine (parce qu’il définit les classes génériques de SPIP, donc il est bon de l’avoir « en commun » à tous les squelettes distribués (sachant qu’il est possible de redéfinir les classes par la suite). On aurait ainsi :

... De la même façon, ce #DOSSIER_SQUELETTE permettrait de livrer des images pour enrichir graphiquement les squelettes, ces images étant installées dans un sous-dossier de son squelette. Par exemple, l’image « fond.jpg » qui serait installée dans : /squelettes/graphique/images/fond.jpg pourrait être appelée, dans le squelette, via un : <img src="#DOSSIER_SQUELETTE/images/fond.jpg">

(3) des fonctions graphiques supplémentaires

J’ai commencé à jouer avec GD2, et il y a quelques fonctions graphiques qui permettent d’obtenir un look carrément professionnel pour pas cher )

 D’abord, des fonctions de création de titres graphiques à partir de texte. Ce qui permet d’exploiter des polices truetype pour créer des titres dans ses propres polices. On trouve ça, il me semble bien, dans Typo3. Ca donne des résultats épatants. Noter que CSS Zen garden, tout en prétendant faire du pur CSS, affiche systématiquement des images pour faire des jolies titrailles.

Au passage, on trouve sur le Web quelques belles polices en GPL, donc on peut livrer des polices avec SPIP sans peine. Et évidemment, il est très simple pour le webmestre d’installer ses propres polices truetype sur son site.

Pour l’instant, je n’ai joué qu’avec GD2, mais ça vaudra certainement le coup de faire la même chose avec Imagemagick.

 Ensuite, quelques fonctions de traitement d’image supplémentaires seraient bienvenues. Actuellement j’ai bidouillé une petite fonction qui extrait une couleur d’une image pour pouvoir l’appliquer à la page (par exemple un gros titre), c’est rigolo mais relativement anecdotique. On peut imaginer quelques fonctions supplémentaires à base de GD2 ou Imagemagick : recadrer une image (par exemple fabriquer des images carrées), passer en noir et blanc, ou selon une teinte spécifique (effet « sépia »), ce qui permet de faire des interfaces radicalement différentes, quoique très cohérentes, à partir de la même base de documents sur un site.

(4) Documents distants et podcasting

Un mail de Fil évoque : "documents distants" + "syndication podcasting", et il a l’air drôlement enthousiaste )

(5) Calendrier public

Emmanuel a beaucoup bossé sur le code du calendrier pour la 1.8, mais ça ne donne pas pour l’instant d’utilisation réellement évidente pour les webmestres sur le site public. Ca serait bien qu’on parvienne à quelque chose de facile et souple de ce côté.

Au passage, je pense que des balises de calendrier public devraient s’appuyer sur des sources iCal, puisqu’on sait très bien (depuis la 1.7 ?) créer des squelettes de fichiers iCal avec SPIP. Non seulement cela permettrait de livrer, en standard, des calendriers fastoches à utiliser, mais aussi cela donnerait une souplesse incomparable aux webmestres qui voudraient personnaliser leurs calendriers, simplement via un squelette iCal (pour ceux qui ne voient pas de quoi je parle, il suffit de regarder le squelette ical.html dans dist, pour voir que ce sont des boucles hyper-simples. Pas bien méchant de personnaliser ça avec des mots-clés, des rubriques, des limites de date, des auteurs, etc.

ARNO*