De l’esprit des thèmes GTK

Je profite de cet article pour mettre quelques notes sur la création et
l’édition de thèmes GTK… A part le fait que c’est un bon divertissement
lors du week-end, j’ai pensé que se plonger là-dedans pourrait non seulement
me faire apparaître les défauts de GTK, mais aussi de me confronter à un
autre genre d’habillage que le CSS. Hé oui, après tout, faire du CSS c’est
appliquer un thème sur un contenu aussi ! Outre ce fait, il est généralement
plaisant de pouvoir travailler dans un environnement satisfaisant pour les
yeux, et étant donné le manque cruel de productions de qualité dans le monde
des thèmes GTK, et surtout de documentation unifiée, je me suis dit que
j’allais noter quelques petites choses que j’avais glanées ici et là. J’ai
décidé d’emprunter à droite et à gauche et surtout de pomper les exemples et
les conseils du tutorial GtkThemes
sur gnome.org
. Merci à son auteur.

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 !

About these ads

10 Responses to “De l’esprit des thèmes GTK”


  1. 1 oelmekki octobre 12, 2008 à 10:52  

    Merci pour cet article sur ce sujet peut abordé :)

    Mais au fait, c’est pas mieux qt? (/me -> {] )

  2. 2 Julien novembre 8, 2008 à 1:04  

    Très très bonne initiative, c’est vrai qu’on trouve pas d’infos en français, j’avais déjàprouvé quelques ‘bidoulles’, mais rien d’aussi complet!

    Juste une erreur relevée
    "Un commentaire (on le démarre n’importe où sur la ligne, c’est tout ce
    qui précède le symbole #"
    => c’est pas plutôt ce qui suit # ?

  3. 3 join novembre 9, 2008 à 8:54  

    Ouais, c’est bien une erreur de français, ça m’apprendra à écrire trop tard. Merci !

  4. 4 playmobitch février 12, 2009 à 5:22  

    merci pour ce super article…on ne trouve pas assez d’info sur les themes GNOME en anglais, alors en français…sympa de partager.
    petite question : par quel moyen peut-on connaître la classe GTK d’un widget donné ? par exemple ces satanées popups de notification qui affichent un texte blanc sur fond blanc avec mon thème…

  5. 5 join février 12, 2009 à 6:46  

    Haha, c’est vrai que ce n’est pas très pratique de faire des thèmes avec GTK étant donné qu’il n’y a aucun outil spécialisé pour le faire, malgré les énormes possibilités d’introspection de GObject.
    Pour arriver à ton objectif, tu as deux moyens :

    Tu regardes le code source d’un programme comme par exemple notify-send (petit programme qui permet d’afficher des popups de notification) et tu repères la classe utilisée. C’est probablement un peu relou.
    Tu installes le moteur de thèmes nommé eXPerience qui doit se trouver pour ta distribution, et tu fais en sorte d’utiliser un de ces thèmes. Ensuite tu te mets dans un terminal et tu lances l’application incriminée (tu peux aussi utiliser notify-send si tu as de la chance) de la manière suivante : EXPERIENCE_PRINT_WIDGET_PATH=TRUE notify-send "Coucou". Cette variable d’environnement permet de dire au moteur de thème d’afficher sur la sortie standard la classe des widgets qu’il dessine. Donc après avoir lancé un popup de notification, tu verras dans ton terminal des noms de classes et tu t’arranges pour trouver le bon. C’est dommage d’utiliser une méthode aussi bizarre pour trouver ça, je recommande fortement à des programmeurs qui s’ennuient de créer un programme pour faire des thèmes GTK :).

    Il se peut que tu n’aies vraiment pas de chance et qu’en réalité ces popups de notification ne soient gérés que par notification-daemon et que quand une application envoie un petit popup du genre, il envoie juste un message DBUS (je crois) pour que le daemon se charge de l’affichage. Mais avant d’en venir aux mains, je te conseille quand même de tester ça.

    A plus.

  6. 6 playmobitch février 13, 2009 à 8:49  

    un début de solution (le moteur eXperience ne m’ayant pas apporté grand chose à part les yeux qui piquent) : http://chipx86.github.com/gtkparasite/

    une sorte de firebug pour gtk…

  7. 7 join février 13, 2009 à 10:41  

    Ouahou, ça a l’air dément ce truc… J’y jette un oeil.

  8. 8 jovial février 28, 2009 à 10:38  

    Merci pour ce document

    Juste le lien suivant est mort

    http://live.gnome.org/GnomeArt/Clearlooks

    Du coup j’ai pas encore trouvé de descriptif sur le moteur clearlook avec une liste des propriétés utilisables

    Bye

    Jean-Luc

  9. 9 join mars 3, 2009 à 9:52  

    Tu peux trouver une description du moteur Clearlooks tout bêtement en regardant les gtkrc du thème Clearlooks par défaut ou de tout thème (récent) qui utilise Clearlooks. Sinon, l’application gnome-color-changer a un éditeur graphique pour certains moteurs dont Clearlooks. C’est à cause de ce programme que certains moteurs de thème incluent maintenant des fichiers .xml qui ont pour fonction de décrire les propriétés du moteur. Regarde de ce côté là. Mais tu verras que ce n’est certainement pas le plus dur à trouver.

  10. 10 Ellis Anderson mai 28, 2010 à 2:14  

    Hehe I am really the only comment to your amazing article?!?


Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s





Suivre

Recevez les nouvelles publications par mail.

%d bloggers like this: