Bonne visite !

Cet article vous propose donc un voyage au pays du rangement automatique à travers une petite recherche pour développer un outil suffisamment flexible pour une utilisation quotidienne. Il peut servir autant aux amateurs de rangement qu’à des gens qui ont envie d’apprendre quelques petites choses avec bash.

Présentation

Mon outil sans prétention est un script bash à exécuter lorsqu’on le désire (je pense au démarrage de la session X ou alors à l’outil cron qui permettrait de l’exécuter tous les jours). Il permet d’utiliser une hiérarchie de dossiers où on peut ranger ses affaires du jour (Documents, Notes, Downloads) de façon transparente (dans un dossier Current). Ce dossier Current est un lien symbolique vers un dossier plus compliqué du style Sorted/février/lundi_02. Un appel au script crée un nouveau dossier si le jour a changé et met à jour une hiérarchie globale où tous les fichiers que l’on trouve pour tous les jours sont centralisés (avec des liens), ce qui permet de retrouver la hiérarchie bordélique que j’utilise chaque jour lorsque je ne me souviens plus de quand j’ai fait tel fichier qui m’intéresse. C’est avant tout un outil pour traiter le travail quotidien et il ne garantit pas d’être utilisable pour archiver des documents. Mais je pense qu’avec quelques améliorations il pourrait être utilisable.

Utilisation

Comment utiliser ce petit script ? C’est très simple : on commence par créer un répertoire vierge et décompresser l’archive du script que l’on trouve ici.

$ mkdir Test
$ cd Test/
$ tar xvzf <chemin>/joinUpdate-pre.tar.gz

L’archive contient deux fichiers : Update qui est le script à appeler, et functions.sh qui est un script auxiliaire contenant des fonctions utiles.

On commence par créer la hiérarchie de répertoires :

$ ./Usage
Creating the Sorted directory...
Creating the Template directory...
Creating the Global directory...
Creating current date directory...
Current directory changed to current date...

Que sont ces répertoires ? On en a trois bien utiles :

• Sorted est le répertoire qui stocke tous les fichiers. On ne dirait pas, parce qu’on ne les utilise jamais directement, sauf pour faire ce pourquoi j’ai créé tout ça : pour naviguer dans ses fichiers classés par jour. Dans le répertoire Sorted on aura donc les répertoires février et février/lundi_02.
• Template est le répertoire que vous allez devoir remplir avec les répertoires que vous voulez centraliser : Documents, Downloads, Projet1, etc. Vous mettez vos répertoires (vides) et ils seront copiés tous les jours, vous assurant ainsi de retrouver toujours les mêmes répertoires tous les jours pour pouvoir encore plus les remplir !
  Si vous avez bien pigé, alors dans votre répertoire Sorted/février/lundi_02 vous aurez les mêmes répertoires que dans Template
• Global est le répertoire qui rassemblera des liens vers tous les fichiers que vous avez créé dans Sorted depuis le début.
• Current est un lien symbolique vers le répertoire du jour courant. C’est celui-là que vous utiliserez dans vos travaux journaliers pour stocker vos fichiers.

On a donc une hiérarchie toute propre, il faut remplir le répertoire de templates :

$ mkdir Templates/Documents
$ mkdir Templates/ProjetJoin

Ensuite on doit appeler le script Update afin qu’il copie ces modèles dans les répertoires Global et Current.

$ ./Update
Documents added to Global from Template.
ProjetJoin added to Global from Template.
Documents updated in Current.
ProjetJoin updated in Current.

Voilà une affaire rondement menée ! Maintenant on peut utiliser le répertoire Current avec plusieurs programmes, on navigue un peu sur Internet, on enregistre quelques pages, tout ça tout ça… Pour l’exemple on va faire un peu plus simple, avec la ligne de commande :

$ echo "Idée 1" > Current/ProjetJoin/idee
$ echo "Bonjour." > Current/Documents/hello
$ echo "12345" > "Current/Documents/Machin Bidule"

Une fois nos documents créés, on peut appeler Update pour qu’il crée les liens vers ces fichiers dans le répertoire Global (on doit le faire dans la journée, car le script ne crée les liens que vers les fichiers de la journée en cours).

$ ./Update
Checking /home/join/src/lntest/Current/Documents...
Checking file hello... Linked into Global.
Checking file Machin Bidule... Linked into Global.
Checking /home/join/src/lntest/Current/ProjetJoin...
Checking file idee... Linked into Global.

Et voilà ! Regardez ce qu’il y a dans Global :

$ find Global/
Global/
Global/Documents
Global/Documents/hello
Global/Documents/Machin Bidule
Global/ProjetJoin
Global/ProjetJoin/idee

Parfait. Si on regarde mieux, tous les fichiers sont des liens symboliques. C’est ce qui m’a amené à considérer un premier problème : dans un but d’intuitivité, il aurait fallu que lorsqu’un fichier de Global est enlevé, sa référence soit enlevée aussi. Malheureusement, pour faire ceci, je n’ai pas encore trouvé une solution sympatique, et puis on supprime toujours trop rapidement. À l’heure où la capacité des supports de stockage est très grande (plus d’un Gio, on va dire), on peut quand même se permettre de ne presque jamais supprimer nos fichiers, tant qu’ils sont rangés (et ils le seront, puisque c’est le but de cet outil). Il faut garder à l’esprit que cet outil est adapté à des petits fichiers comme des travaux que l’on fait (textes, code, graphisme, etc.).

Mises à jour et conflits de noms

Donc là tout est « synchronisé », mais il y a une question qui pose problème (encore !) : si deux fichiers ont le même nom (dans deux jours différents), que se passe-t-il dans Global ? J’ai choisi la solution de facilité (laisser le premier fichier et ne pas mettre l’autre) mais elle pourrait s’avérer avantageuse ou désavantageuse selon les cas (elle force à bien nommer ses fichiers, mais en contrepartie le fait que le dernier fichier créé écrase le reste permettrait de garder des copies de sauvegarde des fichiers et ainsi de pouvoir voir a posteriori leur progression). Faisons un essai et forçons un nouveau Update :

$ ./Update
Checking /home/join/src/lntest/Current/Documents...
Checking file hello... Skipping (exists).
Checking file Machin Bidule... Skipping (exists).
Checking /home/join/src/lntest/Current/ProjetJoin...
Checking file idee... Skipping (exists).

Il ne met aucun lien à jour. Le comportement est bien celui escompté. Afin de garantir l’intégrité de notre répertoire Global, supprimons un fichier dans Current :

$ rm "Current/Documents/Machin Bidule"

Le lien symbolique est maintenant invalide :

$ cat "Global/Documents/Machin Bidule"

cat: Global/Documents/Machin Bidule: Aucun fichier ou dossier de ce type

Un petit appel à Update corrigera tous nos problèmes.

$ ./Update
Checking /home/join/src/lntest/Current/Documents...
Checking file hello... Skipping (exists).
Checking /home/join/src/lntest/Current/ProjetJoin...
Checking file idee... Skipping (exists).
Bad link for /home/join/src/lntest/Global/Documents/Machin Bidule. Deleting.

Ok, très bien. Je vous laisse le soin d’apprécier un usage quotidien du script, vous pourrez même le bidouiller.

Des problèmes, que des problèmes !

Cet outil contre-révolutionnaire présente néanmoins quelques inconvénients :

• Il vérifie tous les fichiers du jour à chaque exécution. Il faut donc définir un mode où il ne fait que des vérifications, et l’exécuter soit au login et à la déconnexion, soit toutes les heures (ou toutes les 5 minutes par exemple).
• Il ne résout pas le problème des conflits lors des mises à jours. J’attends de pouvoir trouver une solution viable (et pas de renommage de fichiers, c’est déplaisant).
• L’utilisation de deux hiérarchies distinctes, mêmes synchronisées, pose des problèmes pour les utilisateurs qui se servent de la fonction « Derniers documents ouverts », à moins que les programmes implémentant cette fonction suivent les liens symboliques et ne gardent que l’adresse de la source. Parce que vu que Current est changé tous les jours, ça pose des problèmes…
• L’utilisation de liens symboliques, c’est bien, mais des liens en dur c’est peut-être aussi bien, voire mieux. Le problème viendra dans la réplication de hiérarchies : avec des liens symboliques, on n’a qu’à faire des liens avec tout ce qui passe, que ce soient des fichiers ou des répertoires, et ça ne pose pas de problèmes pour les répertoires. On ne peut pas faire de lien vers des répertoires en dur. Il faut soit les copier, soit en faire des liens symboliques.
• Que dire de l’utilisation du système de fichiers ? C’est une solution simple, mais peut-être que certains systèmes de fichiers n’aiment pas l’abondance de répertoires que cela va générer.
• Des systèmes de contrôle de version (CVS, SVN, Git…) pourraient faire ce genre de choses et plus encore, moyennant quelques lectures. C’est hélas un peu plus compliqué à appréhender, c’est pas trop fait pour ça et on perd un peu de « sens ».
• Le système actuel est trop attaché aux chemins absolus (mais ce n’est peut-être pas si grave, finalement).
• Au final, par rapport à un outil qui devrait scruter toutes les modifications comme un démon, on n’est pas loin. Et c’est pas très optimisé… Bref, il n’y a peut-être pas de solution qui n’impose pas d’utiliser un démon.

Vous remarquez que j’ai pris le problème dans un sens particulier : le répertoire de bordel contient les liens et le répertoire rangé contient les vrais fichiers, ce qui semblait pratique au premier abord. J’aurais pu faire ça dans l’autre sens, mais une question se pose : je range les fichiers de cette façon (par date, mais j’aurais pu trouver d’autres critères pas forcément temporels) parce que les propriétés des fichiers imposées par le système de fichiers (utilisateur, date de modification, de création) ne me conviennent pas pour trier mes fichiers (et de toute façon je ne connais pas d’outil intuitif et rapide permettant de les grouper grâce à un critère). En regardant le problème dans l’autre sens, comment reconnaître dans un bordel monstre les fichiers qu’on a touché aujourd’hui, sans pouvoir regarder les critères que je viens de citer (surtout la date de modification) ? Si on laisse tomber l’idée de devoir appeler le script à chaque ajout d’un fichier dans le répertoire qu’on veut surveiller (pour le transférer directement), on peut par contre faire de la surveillance de répertoire. Cela nécessite un fichier supplémentaire mais au moins on peut directement garder la trace de toutes les modifications : les fichiers enlevés et les fichiers rajoutés. À la mise à jour (appel du script), il suffit de comparer le dernier fichier chargé de surveiller le répertoire à la hiérarchie de fichiers enregistrés et le compte est bon ! Comment faire ceci ? Voici une solution.

Utiliser find

Nous pouvons obtenir la hiérarchie de fichiers à partir d’un répertoire grâce à la commande find. Créons une hiérarchie de test et enregistrons la hiérarchie (produite par find) dans un fichier à l’extérieur de cette hiérarchie.

$ mkdir test; cd test
$ mkdir rep1 rep2
$ touch fich1 fich2 rep1/fich1 rep1/fich2 rep2/fich1
$ find . > ../hierarchie

Maintenant, supprimons quelques fichiers, rajoutons-en d’autres et observons le résultat.

$ rm rep1/fich2 fich1
$ touch rep1/nouveau pouet
$ find . > ../hierarchie2

On compare les deux :

$ diff ../hierarchie ../hierarchie2 | grep [\<\>]
< ./rep1/fich2
< ./fich1
> ./rep1/nouveau
> ./pouet

Et voilà, on a toutes les modifications de la structure de la hiérarchie de fichiers qui ont été effectuées entre les deux find. On utilise grep pour ne garder que les lignes que l’on veut (diff produit des lignes supplémentaires qui sont des scripts ed, et qui ne nous intéressent pas). Donc si on veut récupérer la liste des fichiers qui ont été supprimés (et donc la liste des fichiers dont le lien symbolique doit être effacé dans la hiérarchie qu’on va maintenir), on fait comme ceci (remarquez ce qui change dans le grep) :

$ diff ../hierarchie ../hierarchie2 | grep [\<] | cut -c 3-
./rep1/fich2
./fich1

L’appel de cut est nécessaire pour enlever les petits signes < ou > qui polluent le nom du fichier.

On peut même faire encore plus fort et n’utiliser que des chemins absolus grâce au programme readlink. Donc au lieu de :

$ find . > ../hierarchie

On ferait :

$ find . | xargs -n1 readlink -f > ../hierarchie

Ici on utilise xargs qui transforme selon des paramètres qu’on définit l’entrée standard en arguments passés à un programme. On doit faire cela car readlink ne joue pas avec l’entrée standard.

Avec tout ça, on pourrait tenter un programme sympathique.

Un nouvel essai

Nous allons donc essayer de suivre le développement inverse : faire un programme qui, à partir d’une hiérarchie de répertoires bordéliques, les classe dans des répertoires selon des critères. Comme critère, on va prendre la date du jour, mais on peut en réalité faire ce que l’on veut. On peut même imaginer que le critère soit une activité donnée par un nom, et qu’une applet GNOME (par exemple) puisse permettre de changer d’activité, occasionnant ainsi la classification dans la nouvelle activité de tous les nouveaux fichiers de la hiérarchie de répertoires à partir de cette date.

On remarque donc que cette manière de procéder est peut-être pas mal plus flexible, puisqu’on n’aurait plus besoin de templates à tenir à jour : tout ce qui est ajouté est pris en compte, donc la structure est extensible à l’infini.

Un peu plus de classe

Après une petite session développement, j’ai fini un outil qui me semble bien. Par rapport au premier jet, il est déjà un peu différent : il suit le principe inverse ! Si je suis déçu de ne pas avoir réussi à utiliser la petite astuce du répertoire Current dont j’étais fier jusque là, je trouve cette nouvelle solution bien plus élégante. Elle utilise une hiérarchie beaucoup moins lourde, moins de répertoires, moins de liens et juste un tout petit peu plus de code.

Je donne un rapide tour d’horizon de la chose. Le programme se nomme toujours Usage sauf que voici son fonctionnement :

$ ./Update -h
Usage: Update [OPTION]
Updates a sorted reference to a file hierarchy grouping them by date or label

        -s              Delete bad symlinks in the sorted reference
        -e              Delete empty directories in the sorted reference
        -l LABEL        Set a particular label

Typical call : Update

Configuration file : ~/.update_postrc
Configuration options (example) :
        SORT_DIR=/home/me/WellStoredFiles
        GLOBAL_DIR=/home/me/ReallyMessyFolder
        dir_cpt=ALabelNameIfYouDontWantToUseDates
(bash syntax)

Haha, ça vous la coupe, non ? Bon, ok… Alors donc voilà. On appelle Update comme avant, sans arguments ni rien. On peut lui passer en paramètre une option ou deux pour lui forcer à faire des opérations de maintenance, dont vérifier la validité des liens symboliques (pas mal utile si on veut garder une hiérarchie à jour), ou alors supprimer les répertoires vides (ce n’est pas obligatoire mais ça peut servir). Une option spéciale permet d’assigner une étiquette aux modifications en cours au lieu d’une date. Il est également possible de définir un fichier de configuration dans son répertoire personnel (dans ~/.update_postrc), ce qui permet de redéfinir les répertoires par défaut de rangement (SORT_DIR) et source (GLOBAL_DIR) puisqu’ils suivent le répertoire d’exécution de Update par défaut. On peut aussi définir dans ce fichier la variable d’environnement dir_cpt qui permet de donner, si on y touche, une étiquette aux prochaines modifications. Afin de faire quelque chose avec ces étiquettes, souvenez-vous que le fichier de configuration est un fichier script bash, vous pouvez donc y importer un fichier, faire des calculs, regarder des dates, ou des tas d’autres choses pour déterminer l’étiquette en cours (ce script est exécuté lors de l’appel à Update).

Ainsi le fait d’utiliser des dates ou des étiquettes a peu d’importance, et ce qui compte c’est l’effet du script. Allons faire un petit essai.

Essai du nouveau script

Voici un petit essai peu commenté du script. D’abord, on a téléchargé l’archive contenant le script Update et on va s’apprêter à créer un dossier de test pour y enfermer ce script et des répertoires divers.

$ tar xvzf <dossier>/joinUpdate-post.tar.gz
$ ./Update
Creating the Sorted directory...
Creating the Global directory...
Creating a new snapshot...
Writing out snapshot date...
Creating a new directory in the sorted structure : 2009_février/02_lundi...

Content de moi, je regarde un peu mon répertoire courant : je trouve deux répertoires qui sont Global et Sorted. Le premier me sert donc pour stocker mes hiérarchies de répertoire et tout mon travail, alors que le deuxième permet de trier tout le bordel par des appels à Update.

On fait quelques fichiers puis on met à jour la structure :

$ mkdir Global/Documents
$ touch Global/Pouetpouet Global/NoteDirection Global/Documents/truc
$ ./Update
Adding ./Pouetpouet...
Adding ./Documents...
Adding ./Documents/truc...
Adding ./NoteDirection...

Génial ! Ça a tout ajouté dans Sorted/2009_février/02_lundi. Ah… J’ai oublié d’ajouter un fichier. Faisons-le.

$ touch Global/oubli
$ ./Update
Adding ./oubli...

Et voilà. Maintenant nous voulons faire une session de travail spécialement pour les minutes à venir. Nous allons utiliser l’option -l avec tous les prochains appels au script pour spécifier une étiquette.

$ touch Global/travailsession Global/jeusession
$ ./Update -l session
Adding ./jeusession...
Adding ./travailsession...
$ ls Sorted/session/
jeusession  travailsession

Ok, maintenant nous n’avons plus envie d’être dans cette session de travail. Faison un Update normal après quelques modifications.

$ rm Global/oubli Global/travailsession
$ touch Global/nouveau
$ ./Update
Creating a new snapshot...
Writing out snapshot date...
Removing ./travailsession...
Removing ./oubli...
Adding ./nouveau...

Voilà donc un outil qui pourrait satisfaire plusieurs utilisations.

Perspectives

Bien sûr, il manque à notre outil une licence un peu plus solide, la localisation (je l’ai fait en anglais pour pouvoir partager plus facilement le code si jamais il servait), et quelques fonctions, mais il m’a l’air bien parti pour une utilisation quotidienne et c’est ce que je vais tester de ce pas. Je ne livre pas la solution clés en main mais il est très facile d’utiliser l’outil pour faire des applets d’environnement de bureau, des démons et toutes sortes de choses.

J’attends toutes vos remarques sur cet article qui m’aura décidément pris plus de temps que prévu.

Petite modification

J’interviens pour une modification de parcours : j’ai rajouté quelques petites lignes pour pouvoir placer la hiérarchie rangée (répertoire Sorted) à l’intérieur de la hiérarchie bordélique (répertoire Global).

Téléchargement

• Version pre (la première qui utilisait les dossiers rangés comme référence)
• Version post (la deuxième qui utilise les dossiers bordéliques comme référence)

Ce travail est soumis à la WTFPL. Respectez-la .

Les descriptions de police Pango

GTK utilise Pango pour afficher du texte. On utilise donc dans l’attribut
font_name une description Pango (incomplète, cependant). Pango
comprend ici seulement les familles de police (c’est-à-dire le nom de la
police; différents noms peuvent être mis, séparés par une virgule), les
styles (bold, italic, condensed,
extended…), la gravité (sens d’écriture : north,
south, east, west) et la taille (en
points, ou la taille en pixels si elle est suffixée de px). Tout
ça séparé par des espaces et dans cet ordre :

famille1,famille2 style1 style2 taille

Aucun des attributs n’est obligatoire, ce qui fait qu’on peut garder la
famille de police mais changer la taille, garder le style et changer la
famille de police… Ainsi, pour garder la police de l’utilisateur mais
changer sa taille, on mettra :

font_name = "8"

Pas mal, hein ?

Une super aubaine !

Ceci nous permet, en plus d’avoir des thèmes génériques par rapport aux
familles de polices, d’appliquer des contraintes de polices indépendamment du
thème appliqué ou de la police choisie. C’est ce que j’ai expérimenté sous
GNOME (mais ça marche partout) où j’ai rempli mon fichier
~/.gtkrc-2.0 avec le code ci-dessous. La particularité de ce
fichier est qu’il est prioritaire par rapport à tous les autres
rc de thèmes :

############################
#   Polices                #
############################

style "label_fnt" {
font_name = "8"
}
widget_class "*<GtkLabel>*" style "label_fnt"
widget "gtk-tooltip*" style "label_fnt"
widget_class "*GtkExpander*" style "label_fnt"

style "menu_fnt" {
font_name = "9"
}
widget_class "*GtkMenu*" style "menu_fnt"

style "statusbar_fnt" {
font_name = "8"
}
widget_class "*Statusbar*" style "statusbar_fnt"

style "notebook_fnt" {
font_name = "Bold 8"
}
widget_class "*.GtkNotebook.GtkLabel*" style "notebook_fnt"

style "frame_fnt" {
font_name = "Bold 8"
}
widget_class "*.GtkFrame.GtkLabel*" style "frame_fnt"

style "button_fnt" {
font_name = "9"
}
widget_class "*.Gtk*Button.*Label" style "button_fnt"

style "checkradio_fnt" {
font_name = "9"
}
widget_class "*.GtkCheckButton.*Label" style "checkradio_fnt"
widget_class "*.GtkRadioButton.*Label" style "checkradio_fnt"
widget_class "*.GtkComboBox*.*Label" style "checkradio_fnt"

style "toolbar_fnt" {
  font_name = "7"
}
widget_class "*.<GtkToolbar>.*Label" style "toolbar_fnt"
widget_class "*.<GtkToolbar>.*GtkComboBox*" style "toolbar_fnt"
widget_class "*.<GtkToolbar>.*GtkEntry*" style "toolbar_fnt"
widget_class "*.<GtkToolbar>.*Gtk*Button*" style "toolbar_fnt"

# Panel items
style "panel_fnt" {
font_name = "8"
}
widget_class "*Panel*" style "panel_fnt"

Génial ! Maintenant, prenez un thème, une police, et c’est parti.

Un exemple

Voici la différence entre un thème avec et sans ces modifications :

C'est moche !

C'est mieux !

Bien sûr, j’avais ici une police de taille 9 par défaut, et j’ai mis du 9 sur les boutons, les checkboxes… Ce qui ne change pas beaucoup de choses ! Mais libre à vous de changer les tailles et de mettre tout sans dessus dessous (indice : north).

La structure d’un thème

Un thème, c’est avant tout un dossier, dans la spécification Freedesktop.
Le nom du dossier indique le nom du thème, et il est placé dans un répertoire
themes. Dans ce dossier sont rangés un ou plusieurs dossiers portant le nom
de l’application ou de la librairie qui l’utilise. Par exemple,
xfwm4 ou gtk-2.0. Et dans chaque dossier sont
rangés des fichiers ayant une structure propre à leur application.

Pour GTK, on aura un fichier gtkrc qui sera le point de
départ de ce qui sera interprété pour afficher le thème. C’est un fichier
avec une « instruction par ligne », où chaque instruction peut être :

• Un commentaire (on le démarre n’importe où sur la ligne, c’est tout ce
  qui suit le symbole #, ou alors il peut avoir effet sur
  plusieurs lignes et dans ce cas c’est tout ce qui se situe entre
  /* et */)
• Une propriété, qu’on écrit : propriété = valeur
• Une définition de style, qu’on écrit style "nom du style"
{, suivi de lignes de propriétés, puis de }. On peut
  hériter d’un autre style déjà défini en écrivant plutôt style "nom
du style" = "nom du style hérité"
• Une affectation de style, qu’on écrit : class "ClasseGtkAffectée"
style "style choisi"

Cette liste pas exhaustive, nous verrons d’autres « instructions » au fil de
l’article. Il est possible de séparer les styles dans plusieurs fichiers rc
et de les inclures dans le gtkrc général. On verra qu’il est possible
d’employer des images que l’on placera dans le répertoire du thème GTK.

Mettons-nous donc à l’ouvrage et construisons notre premier thème GTK sans
plus attendre. Sous les systèmes apparentés aux UNIX (GNU/Linux, *BSD…), on
trouvera les thèmes Freedesktop dans un dossier global au système, du genre
/usr/share/themes, et aussi dans un dossier local à
l’utilisateur, qui est ~/.themes. Allons donc créer un dossier
1test dans ce répertoire de thèmes (s’il n’existe pas, il faudra
le créer avec la commande mkdir ~/.themes) :

cd ~/.themes

mkdir 1test

Continuons avec la création d’un répertoire gtk-2.0 :

mkdir 1test/gtk-2.0

cd 1test/gtk-2.0

On peut maintenant créer un nouveau fichier gtkrc et l’éditer
avec notre éditeur préféré (ici le mien c’est vim, sans
concession) :

vim gtkrc

Vous voilà dans un fichier vide ! Avant de commencer à tapoter des lignes,
voyons donc quelques bases.

Une hiérarchie pour les gouverner tous

Un widget, c’est un élément d’interface utilisateur dans GTK. Ça peut être
un bouton, une étiquette de texte, un menu… Tous les widgets de GTK sont
inscrits dans une hiérarchie et ce sont tous des objets (au sens de la
programmation orientée objet). Ainsi, tous les widgets possibles et
imaginables « descendent » de GtkWidget : peu importe sa place
dans la hiérarchie, il conservera les propriétés de ce GtkWidget
(pour peu qu’on ne les modifie pas). Dans le même ordre d’idées, un
GtkColorButton (qui est un bouton pour choisir des couleurs dans
l’interface) hérite des propriétés de son père le GtkButton, qui
lui-même hérite des propriétés de GtkWidget. Bien entendu, rien
ne nous empêche de remettre en cause les propriétés de GtkButton
qui ont été héritées de GtkWidget. C’est comme ça qu’on peut
tout contrôler.

On verra plus tard qu’il faudra séparer, comme en programmation orientée
objets, le concept de classe de celui d’instance de classe.
Pour faire simple, une classe est un type d’objet et une instance est un
objet du type. Par exemple, Richard Stallman est une instance de la classe
SuperHéros signifie que Richard est un super héros et partage donc les
caractéristiques des super héros, mais il est toutefois unique. Du fait que
c’est un super héros, il contribue à sauver le monde de la destruction, comme
le font tous les super héros. Pour pousser plus loin notre exemple, on peut
même remarquer que SuperHéros est une classe qui hérite de la classe Mec,
c’est-à-dire qu’un super héros est un mec avant tout. On peut lui parler, ou
lui dire « Hé, t’es une mauviette ! », comme à tous les mecs. Si on imagine que
tous les super héros répondent de la même manière que les mecs normaux à mon
« Hé, t’es une mauviette ! », on peut quand même imaginer qu’il y aurait une
classe SuperHérosPasCool qui hérite de la classe SuperHéros et dans laquelle
le comportement du super héros pas cool à mon « Hé, t’es une mauviette ! »
aurait été changé. Au lieu de danser la zoubida, comme tous les mecs normaux,
ce genre de super héros pas cool pourrait très bien me répondre « Personne ne
me traite de mauviette ». Bref, ce paragraphe était là pour rappeler aux
nouveaux dans le monde objet quelques principes, et je m’excuse d’avance s’il
vous a plus mis dans le flou qu’éclairci les idées. De nombreux sites et
cours sont à disposition sur la toile pour poser clairement ces concepts.

Je parle de tout ce charabia car il est important de savoir que GTK étant
programmé en objets (malgré qu’il soit en C, ce qui n’est pas une mauvaise
chose en soi), la hiérarchie de ses widgets est une hiérarchie de classes qui
existe dans la librairie et qui est très bien documentée. Pour vous en
convaincre, installez la doc de GTK (gtk-doc sous la majorité
des distributions) et un fabuleux lecteur de documentation nommé
devhelp. Sinon, faites un tour sur le site de GNOME, tout est
marqué ici. Toutes
les propriétés stylistiques de ces classes, et même des instances, sont
gérées par un mécanisme de propriétés changeables ou lisibles directement
dans un programme, en direct live ! Nous allons nous contenter de les « graver
dans la roche » pour nos familles et nos… amis.

Un accès plus facile à la propriété ^{partie 1}

On va voir comment écrire une propriété, et ensuite on verra où la mettre.
Une propriété, c’est une ligne qui définit un changement d’attribut d’un
widget. Par exemple, sur la
de doc du widget GtkComboBox, qui définit une boîte de
sélection, on peut lire tout un tas de propriétés et de propriétés
stylistiques vachement intéressantes. On peut toucher à tout en respectant
les types des valeurs qu’on donne aux propriétés de style. En règle générale,
dans le fichier gtkrc, on va appliquer une propriété X à une classe Y en
écrivant :

Y::X = valeur

On ne peut pas l’écrire n’importe où : on doit créer un
style dans lequel on va inclure cette propriété, et appliquer le
style à une classe de widgets. Ça a l’air compliqué, mais en fait c’est
simple : il faut toujours mettre ses directives (propriétés
de style, propriétés, couleurs, moteurs de thème…) dans des styles, sauf si
ces directives sont des propriétés globales (par exemple
gtk_color_scheme) ou des applications de style. En gros, sauf
dans deux cas, on met ses propriétés dans les styles et basta.

Imaginons que je veuille directement modifier une propriété de
GtkComboBox qui permet aux éléments de la liste déroulante
d’être affichés comme une liste et non pas comme un menu. On va utiliser la
ligne de propriété : GtkComboBox::appears-as-list = 1. On va
devoir la mettre dans un style qu’on nommera… comme on veut ! Et on
l’appliquera à la classe GtkWidget, comme ça on s’fait pas
chier. Comment on fait ? Vous devriez pouvoir trouver avec tout ce que j’ai
dit au dessus :

# Petit thème moche
# par join et <entre ton nom ici>

style "styleParDefaut" {
    GtkComboBox::appears-as-list = 1
}

class "GtkWidget" style "styleParDefaut"

Et voilà.

Interlude : Tester un thème

Il existe plusieurs moyens de tester notre thème fraîchement composé. Pour
les utilisateurs de GNOME, il est toujours possible, quoique très lent, de
passer par les préférences de l’apparence. Je vous conseille toutefois un
outil comme The Widget
Factory (disponible dans des dépôts pour votre distribution si vous avez
de la chance). Une fois compilé et/ou installé, lancez cet outil en
l’appelant par son nom, de préférence en ligne de commande :

twf

L’avantage d’avoir nommé notre thème de test 1test est qu’il
est possible de le charger facilement : il est normalement en première place
du menu de sélection de thèmes ! Un clic sur le bouton Actualiser de
la barre d’outils permettra d’afficher les modifications que l’on vient de
faire subir à son thème. Le fait d’avoir lancé The Widget Factory en ligne de
commande permet de voir dans le terminal, à l’actualisation du thème, tous
les messages d’erreur qu’envoie GTK lorsqu’il lit le thème, autrement dit
toutes les erreurs de votre thème.

Vous voyez que notre premier thème est bien moche et qu’on a du pain sur
la planche. Ziva !

Un accès plus facile à la propriété ^{partie 2}

Les propriétés de style décrites plus haut sont décrites dans une
liste super sympa.

Il y a un autre genre de propriétés à spécifier, elles s’appliquent au
style dans lesquelles elles sont et n’ont pas besoin de préfixe du genre
NomDeClasse::. Nous allons en voir plein, mais on peut déjà
s’attarder sur quelques uns. xthickness et
ythickness permettent par exemple de fixer l’espacement
horizontal et vertical entre le contenu du widget et ses bords. Testons donc
ce thème :

style "styleParDefaut" {
    xthickness = 7
    ythickness = 7
}

class "GtkWidget" style "styleParDefaut"

Un petit coup de Actualiser dans le Widget Factory vous montrera
que tous les widgets sont énormes, ce qui est le défaut qu’on prête à GTK en
général. Changez les 7 par des 1 et vous allez voir un thème tout compact.
Évidemment, avec la face qu’ont les widgets de GTK lorsqu’ils sont tous nus,
c’est pas beau à voir, et en plus ça bouffe les bordures. Mais vous savez que
vous pouvez déjà contrôler un paramètre.

Ajouter de la couleur

On va bientôt pouvoir peinturlurer tous nos widgets en comprenant comment
on leur rajoute des couleurs. C’est une ligne à mettre dans un style qui a
cette tête-là :

categorie[ETAT] = couleur

Quelles sont les quatre catégories, les cinq états et les différentes
manières de mettre une couleur ? J’ai regardé un peu la doc de GTK pour
résumer tout ça…

Catégories de couleurs

fg

C’est la couleur du premier plan (foreground color) qui définit en
général la couleur du texte des widgets d’affichage (menu, label,
bouton…). Il paraît que c’est utilisé parfois pour contrôler la
couleur de la bordure.

bg

C’est la couleur du fond des widgets d’affichage.

text

C’est la couleur de premier plan (de texte) des widgets d’entrée
(liste, boîte d’entrée de texte, tout ce qui apparaît sur fond blanc
dans Widget Factory quoi).

base

C’est la couleur de fond des widgets d’entrée.

États des widgets

NORMAL

C’est la couleur par défaut du widget dans une catégorie donnée.

PRELIGHT

C’est la couleur lorsque la souris pointe le widget (le
hover en quelque sorte).

ACTIVE

C’est la couleur lorsque le bouton de la souris est enfoncé.

INSENSITIVE

C’est la couleur de l’état inactif (quand on ne peut pas utiliser
l’élément).

Couleur arbitraire

On peut définir une couleur de manière arbitraire en la notant entre
guillemets en notation hexadécimal. J’ai l’habitude de la noter comme tout le
monde fait en CSS : "#RRVVBB". On peut aussi utiliser un triplet
de valeurs (en format virgule flottante, c’est-à-dire avec un point
obligatoire qui fait office de virgule) de rouge, vert et bleu de ce style :
{1.0, 0.45, 0.3}, c’est-à-dire des valeurs réelles entre
0.0 et 1.0. Il y a d’autres manières de noter les
couleurs, pour toute l’info allez voir les liens en fin de document.

Couleur symbolique

Il est possible, depuis GTK+ 2.10, d’utiliser des couleurs symboliques,
c’est-à-dire des variables qui vont pouvoir servir plusieurs fois (il n’est
alors pas nécessaire de changer toutes les occurences d’une couleur dans un
thème, il suffit de changer la valeur de la couleur symbolique). On définit
une couleur symbolique à l’intérieur d’un style de cette façon :

color["nom_de_la_couleur_symbolique"] = "#0F1030"

On peut alors l’utiliser, par exemple dans une ligne telle que :

bg[NORMAL] = @nom_de_la_couleur_symbolique

Malheureusement, c’est un peu pourri, comme manière de fonctionner : la
couleur n’a pas d’existence en dehors du style. C’est une limitation que l’on
peut néanmoins éviter grâce aux color schemes. C’est un truc qui
permet de changer les couleurs du thème sans changer de thème : un truc pour
personnaliser un thème à sa sauce. GNOME permet de modifier ces color schemes
dans la fenêtre d’apparence. On définit le color scheme par défaut en dehors
d’un style, en général au début, avec une propriété nommée
gtk_color_scheme qui se joue comme ça :

gtk_color_scheme = "color1:#001\ncolor2:Blue"

On n’a pas le droit de mettre d’espaces et on sépare les définitions de
couleurs de leur valeur par un :, tandis qu’on sépare les
différentes définitions entre elles par un \n. J’ai chopé un
exemple très bien dans la doc de GTK :

gtk_color_scheme = "fg_color:#000\nbg_color:#ede9e3\nbase_color:#fff\ntext_color:#000\nselected_bg_color:#5598d7\nselected_fg_color:#fff"

style "default"
{
  fg[NORMAL]        = @fg_color
  fg[PRELIGHT]      = @fg_color
  fg[SELECTED]      = @selected_fg_color
  fg[ACTIVE]        = @fg_color
}
#(le thème n'est pas écrit complètement)

On utilise donc les couleurs définies là-dedans avec un @.

Opérations sur les couleurs

On peut effectuer des opérations sur ces couleurs et même les faire en
cascade :

mix(valeur, couleur1, couleur2)

Mélange couleur1 et couleur2 selon la
proportion valeur (entre 0.0 et 1.0).

shade(valeur, couleur)

Change la luminosité et la saturation de couleur avec
valeur (si c’est 1.0, ça change rien).

lighter(couleur)

C’est un raccourci vers shade(1.3, couleur).

darker(couleur)

C’est un raccourci vers shade(0.7, couleur).

Les couleurs symboliques avec lesquelles on travaille habituellement sont
celles qu’utilise GNOME pour ses color schemes personnalisés. Il est
recommandé de les suivre. Il s’agit de fg_color,
bg_color, base_color, text_color,
selected_bg_color, selected_fg_color,
tooltip_bg_color et tooltip_fg_color. Leur
signification tombe sous le sens.

Un pour le style, deux pour le spectacle

Maintenant qu’on sait ajouter des couleurs, des propriétés de style très
spécifiques et des couleurs dans tous les sens, nous allons approfondir un
point que nous avons un peu délaissé. On sait donc créer des styles, qui sont
des regroupements de propriétés. Il faut maintenant les appliquer à des
widgets. Pour cela on a trois choix.

Application à une classe

On a déjà rencontré la directive class plus haut, par exemple
dans :

class "GtkWidget" style "styleParDefaut"

Ici, on applique à la classe GtkWidget (c’est-à-dire à tous
les widgets) le style styleParDefaut. On peut utiliser
* dans le nom de classe pour spécifier « ce que tu veux » et
? pour « le caractère que tu veux. La doc donne l’exemple de
"Gt?T*" qui va convenir pour GtkToggleButton. Donc
si on avait :

class "Gt?T*B*n" style "style1"

Alors style1 s’appliquerait à GtkToggleButton
(et à d’autres classes qui remplissent le critère).

Application à des imbrications de widgets ou à un widget particulier

On va voir la directive widget_class qui fait la même chose
que class sauf qu’on ne sélectionne pas les classes de la même
façon. Ici on regarde l’imbrication des widgets les uns dans les autres. Par
exemple, si j’ai une fenêtre dans laquelle il y a un bouton, et que dans ce
bouton il y a une étiquette de texte, alors comment pourrais-je appliquer un
style uniquement à l’étiquette de texte ? On regarde ce que la doc appelle le
Classpath du widget. Celui de la fenêtre est :
GtkWindow. Celui du bouton dans la fenêtre est :
GtkWidget.GtkButton, et celui de l’étiquette de texte dans le
bouton est : GtkWidget.GtkButton.GtkLabel. Avec
widget_class, on peut utiliser * pour dire « tous
les genres de classes » et des . comme séparateurs. On peut donc
trouver notre étiquette de texte par la chaîne de caractères
"*.GtkButton.*", mais aussi par
"*.GtkButton.GtkLabel". Si l’on veut maintenant trouver non
seulement GtkWidget.GtkButton.GtkLabel mais aussi
GtkWidget.GtkToggleButton.GtkLabel, ça va pas marcher comme ça
en claquant des doigts. Au lieu d’utiliser "*.GtkButton.*", on
va utiliser "*.<GtkButton>.*". GTK va prendre, en seconde
position, un GtkButton ou toute classe héritée, donc par exemple
un GtkToggleButton. Un petit exemple :

widget_class "*.<GtkButton>.*" style "contenu-bouton"

Notons que * ou ?, s’ils remplacent un ou
plusieurs caractères, peuvent aussi remplacer des caractères ..
Je m’explique : "GtkW*n" pourra reconnaître
GtkWidget.GtkButton aussi !

Vous pouvez aussi widget au lieu de
widget_class. Vous pourrez prendre un nom de widget bien défini
dans le classpath.

Ordre des assignations de style

Lorsque plusieurs assignations de style peuvent recouvrir un même widget,
on a souvent affaire à des conflits : quel style sera appliqué en premier,
qu’est ce que ça va donner à la fin ? De plus, certains widgets ne peuvent
pas être modifiés comme ça et on peut mettre des priorités aux assignations
de style. Pour plus d’infos, je vous renvoie à la doc de GNOME.

Polices ! Vos papiers !

Je vous renvoie à mon nouvel article sur les polices pour vous aider un peu.

Moteurs !

Super, join vous a appris à faire des thèmes avec des couleurs partout,
mais il y a un problème : comment on change ces widgets en 3D au look de
W?nd?ws 95 ?

Héhé… Je ne sais pas… Allez, je crache le morceau : vous avez très
probablement déjà installé (même sans le savoir) des theme engines,
c’est-à-dire des moteurs de thèmes qui permettent de dessiner des widgets
complexes grâce à des images ou en vectoriel. Le thème par défaut sous GNOME
utilise un moteur de thème du même nom : il est grand, il est beau, c’est
Clearlooks ! Il en existe des autres, beaucoup d’autres, et
il y a pas mal de paramètres pour chaque moteur.

On utilise un moteur à l’intérieur d’un style, ce qui
veut dire qu’on peut tout mélanger dans tous les sens : un bout de Clearlooks
par ci, un bout d’Aurora par là…

Comment on fait ça ? La syntaxe est simple :

engine "nom_de_l'engine_en_minuscules" {
    # propriétés du moteur
}

Vous avez droit à une liste d’engines (et peut-être leurs propriétés) sur le site de
GNOME.

Inclusion de thèmes

Avant de commencer à voir des exemples et des cas particuliers, je tiens à
revenir sur un point : je parlais tout à l’heure de séparer le thème en
plusieurs fichiers rc. Ça peut être pratique pour ne pas
s’embrouiller dans les thèmes, ou alors de faire plusieurs versions du même
thème sans tout réécrire. On utilise la directive globale
include et on la met à la place où on voudrait que le fichier
soit inclus :

include "fichier"

Exemple : du Clearlooks !

On va choisir une palette de couleurs et appliquer un moteur Clearlooks
dessus. Vous devriez déjà avoir ce moteur dans votre distribution, si elle
n’est pas trop vieille, et sinon il ne doit pas être difficile à trouver.

Choix des couleurs

Pour ce premier thème, je veux cette palette de couleurs :

On va déjà penser à fabriquer la ligne qui donne le ton de couleurs par
défaut :

gtk_color_scheme = "fg_color:#2e3436\nbg_color:#d1c7b4\nbase_color:#ede3d0\ntext_color:#000000\nselected_bg_color:#d1c7b4\nselected_fg_color:#2b64a8\ntooltip_bg_color:#b8a587\ntooltip_fg_color:#000"

Maintenant qu’on a cette ligne on peut assigner à un style par défaut les
couleurs ainsi choisies. Vous pouvez utiliser les lignes ci-dessous comme
modèle pour vos futures compositions. Ce sont les lignes de couleurs par
défaut du thème Clearlooks.

fg[NORMAL]        = @fg_color
fg[PRELIGHT]      = @fg_color
fg[SELECTED]      = @selected_fg_color
fg[ACTIVE]        = @fg_color
fg[INSENSITIVE]   = darker (@bg_color)

bg[NORMAL]        = @bg_color
bg[PRELIGHT]      = shade (1.02, @bg_color)
bg[SELECTED]      = @selected_bg_color
bg[INSENSITIVE]   = @bg_color
bg[ACTIVE]        = shade (0.9, @bg_color)

base[NORMAL]      = @base_color
base[PRELIGHT]    = shade (0.95, @bg_color)
base[ACTIVE]      = shade (0.9, @selected_bg_color)
base[SELECTED]    = @selected_bg_color
base[INSENSITIVE] = @bg_color

text[NORMAL]      = @text_color
text[PRELIGHT]    = @text_color
text[ACTIVE]      = @selected_fg_color
text[SELECTED]    = @selected_fg_color
text[INSENSITIVE] = darker (@bg_color)

Vous pouvez remarquer que des effets sont déjà appliqués sur les
PRELIGHT, les ACTIVE et les
INSENSITIVE. On peut bien sûr changer ces effets à volonté.

Vous allez remarquer que nous aurons à rajouter des directives de couleurs
pour des endroits particuliers, car certains widgets n’utilisent pas les
couleurs comme d’autres.

Configuration du moteur Clearlooks

Nous allons utiliser le moteur Clearlooks. Il nous faut un peu de
documentation. Pour l’obtenir, on peut regarder sur
href= »http://live.gnome.org/GnomeArt/Clearlooks »>le site de GNOME où les
explications sont claires mais peu nombreuses, et en éditant le thème par
défaut Clearlooks, par exemple, qui se trouve sur mon système à
/usr/share/themes/Clearlooks/gtk-2.0/gtkrc. On peut bidouiller
pour configurer le thème comme on le veut. Ici j’ai choisi quelques
paramètres sympas :

engine "clearlooks" {
    style = GUMMY
    radius = 3.5
    contrast = 1.0
    scrollbar_color = @selected_bg_color
    menubarstyle = 1
    animation = TRUE
}

Moi, je trouve ça bien.

Configuration par défaut des widgets

On va changer deux ou trois petites choses qu’on peut mettre dans le style
par défaut.

Déjà, on va faire en sorte que le contenu des boutons ne se décale pas
lorsqu’on laisse la souris appuyée dessus.

GtkButton::child-displacement-x = 0
GtkButton::child-displacement-y = 0

Voilà. On en a fini avec le style par défaut. On l’appellera
base et on l’assignera à tous les widgets par la sentence :

class "GtkWidget" style "base"

Un petit truc

On va faire comme 80% des thèmes GTK. Il faut créer des styles avec
différentes valeurs pour xthickness et ythickness
afin de pouvoir les appliquer simplement aux widgets que l’on veut, et ce
pour factoriser des paramètres.

style "small" {
    xthickness = 1
    ythickness = 1
}

style "medium" {
    xthickness = 2
    ythickness = 2
}

style "large" {
    xthickness = 3
    ythickness = 3
}

style "xlarge" {
    xthickness = 4
    ythickness = 4
}

Il y en a peut-être trop, mais tout dépend de ce qu’on va utiliser.

Boutons

On va personnaliser les boutons en leur mettant une police et en réduisant
leur place sur l’écran.

style "bouton" = "medium" {
    GtkButton::inner-border = {0, 0, 0, 0}
    font_name = "Arial 8"
}

On applique maintenant le style aux boutons et aux textes dans les
boutons. On utilise widget_class et non pas class
pour des raisons que l’expérience vous montrera…

widget_class "*<GtkButton>*" style "bouton"

Menus

Les textes des menus qui sont sélectionnés par la souris sont en noir sur
fond bleu, c’est moche ! Mettons une couleur un peu plus pétante et
élargissons un peut tout ça en faisant hériter le style du style
large :

style "menuitem" = "large" {
     fg[PRELIGHT] = lighter(@selected_fg_color)
}

On applique le style façon porc :

widget_class "*GtkMenu*" style "menuitem"

Zones d’édition

Si on lance TWF avec notre thème, on s’aperçoit de deux choses :

1. Il est moche
2. Les zones d’édition empiètent sur leurs bordures

Hé oui, une zone d’édition est un rectangle, il lui faut un peu de place.
Heureusement on peut prévoir extra-large :

widget_class "*<GtkEntry>*" style "xlarge"

Le thème en entier

Tout notre thème est contenu dans ces lignes. A vous de rendre
ce thème beau, en utilisant toutes les ressources que vous aurez accumulées
tout au long de cet article.

Moralité

On voit quand même que le CSS et ses sélecteurs, c’est pas si mal foutu
que ça ! Je pense qu’il faudrait à GTK un parseur de thèmes plus flexible sur
la syntaxe et beaucoup plus de variables. Par exemple, il serait bien de
pouvoir spécifier uniquement la taille de la police d’un élément dans un
style. Bref, à l’heure où aucun outil graphique ne facilite la mise en place
de thèmes GTK, surtout quand on sait que le travail ne serait pas beaucoup
facilité, il est nécessaire de se faire la main sur des thèmes déjà faits en
comprenant les quelques règles qui ont été expliquées ici afin d’arriver à
ses fins. Je ne pense pas que la création de thèmes soit sans limite à
l’heure actuelle, mais en combinant toutes les bidouilles, il est possible
d’arriver à quelque chose de fort sympathique et qui convient à tous les
besoins. Force est de constater que dans de nombreux thèmes qui tournent très
bien, une bonne part est réservée aux hacks, c’est-à-dire aux
petites corrections d’apparence spécifiques à un seul logiciel (Evolution a
donné du fil à retordre à beaucoup d’artistes, me semble-t-il).

Si toutefois vous aimez les bonnes nouvelles, alors tendez vos oreilles… Il paraît qu’un moteur GTK va sortir et permettra la description de thèmes en CSS. Je vous invite à lire cet article et à suivre régulièrement l’affaire !

J’espère avoir été assez clair pour permettre à des gens de s’affranchir
des docs en anglais qui existent sur le sujet, et en avant pour un prochain
post !

.classeDeLElement:before {

content: "Madame la Marquise a dit : ";

}

Ce contenu a la fâcheuse tendance à ne pas accepter de HTML, ce qui ne laisse pas libre cours à toutes les folies non validées par le W3C. Il est tout de même possible de faire des choses assez rigolotes comme rajouter une image, mettre un compteur qui s’incrémente (pour pouvoir faire de la numérotation, par exemple).

On peut tout mettre en même temps comme ceci :

.classeDeLElement:before {

content: url('images/icone.png') counter(compteur1);

padding-right: 5px; /* éloigner le rajout de 5 pixels */


}

Ainsi, on peut jouer avec quelque chose d’intéressant, qui peut nous donner une belle image et être repositionnée par rapport au contenu de la balise concernée. En réalité, il y a un problème, c’est qu’une image n’est pas toujours forcément bien alignée avec le texte. On peut croire être sorti(e) d’affaire en utilisant un coup de padding, mais la propriété CSS padding-bottom ne marche pas avec les pseudo-éléments before et after, du moins avec Gecko… Et on ne va pas mettre une balise img en plein dans notre code HTML, ça serait blasphématoire pour le principe de séparation du contenu et de la présentation (en admettant que les petites images qu’on mettra avant ou après ces balises sont des trucs uniquement tape-à-l’oeil, comme des petits points d’interrogation ou des petites icônes sympa, et non pas des images porteuses de contenu). Ce qu’il y a de pratique avec ce genre de balises img c’est la possibilité d’aligner verticalement l’image au contenu textuel l’englobant directement avec un paramètre de la balise, en bourrinant avec du HTML dont la conformité aux standards actuels émet plus que l’ombre d’un doute. Comment remplacer cette fonctionnalité en utilisant des :before ou des :after ?

J’ai cherché çà-et-là sur toute une tripotée de sites et pas un seul site n’a été foutu de cracher le morceau sur cette histoire. En attendant de réviser mes compétences en recherche sur goo – le – site – le – presque – plus – vu – au – monde – et – dont – les – possesseurs – seront – bientôt – les – maîtres – du – monde – gle, j’ai décidé de me mettre à bidouiller. J’ai utilisé la super astuce de la balise <span> qui arrange tous les problèmes (aussi vue dans l’affaire du remplacement de texte par une image en CSS). Je n’ai pas le temps ni l’envie de voir le résultat dans IE mais si un(e) internaute courageux/se veut se proposer, qu’il/elle se montre !

Voilà la marche à suivre. Ici, on a le code HTML :

<div class="faireattention">Il faut suivre la recette à la lettre !</div>

Et le CSS :

div.faireattention {

/* tout un tas de propriétés chouettes */


}

div.faireattention:before {

content: url("images/attention.png") "> ";

}

Alors, ça marche pas ? C’est normal, il faut procéder aux changements suivants. Revoilà le bon HTML :

<div class="faireattention"><span></span>Il faut suivre la recette à la lettre !</div>

Et le bon CSS :

div.faireattention { /* ... */ }

div.faireattention > span {

position: relative;

top: 3px; /* baisse l'image de 3 pixels */


}

div.faireattention > span:after {

content: url("images/attention.png") "> ";

}

Ca donne à peu près ça :

Aperçu sympa

Comme on peut le remarquer, il y a tout de même un problème de fond : qu’on mette un after ou un before, ça revient au même. En plus de pourrir notre HTML, on perd en flexibilité dans le CSS (« quoi ? le mec il nous donne des astuces et après il dit qu’elles sont pourries ! »).

Néanmoins, il ne faut pas s’inquiéter, ça conviendra dans une grande partie des cas et si quelqu’un a une meilleure solution, qu’il vienne la faire partager !

Vous avez droit aussi au code de la page d’exemple qui vous révèlera que cette astuce malhonnête de positionnement a des répercussions sur le placement des div qu’on voit leurs bordures. C’pas ben grave.