A part le rejet pur et simple, as tu un réel argument pour ne pas utiliser CSS dans GTK ?
Dans l'ordre :
a) C'est pas fait pour ça - Il existe certes des bibliothèques (le plus souvent en javascript) qui permettent de transformer certains éléments CSS en widgets, mais le CSS est un descripteur de style, c'est à dire qu'il sert à normaliser la mise en forme du contenu. S'en servir pour du contenant ne fait pas sens. Cela fait d'autant moins sens que GTK3 possède déjà un moteur de style qui lui est propre - et qu'une partie du fonctionnement interne est inaccessible depuis les CSS, le role de CSS dans le cadre du thème est donc batard :
- Il peut influencer le contenu (via margin , padding, font etc.) mais pas complètement le mettre en forme
- Il peut faire le thème mais pas complètement (il n'y a pas de "retour" en CSS - il faudra donc de toute façon écrire de la logique hors CSS pour le comportement avancé des widgets)
- Il rend le test des applications très complexe : comme les CSS GTK3 ne gèrent pas (encore ? apparament ca ne sera pas fait) l'ajustement automatique de la taille, un élément rendu trop grand par une CSS innapropriée sera tronqué. Comme il est décommandé de créer son propre moteur de theme, on arrive à des situations ou la barre de menu peut avoir été décalé sur le coté alors que vos widgets dans cette barre sont en long. Au final soit on force un thème complet ou presque dans l'appli (mais alors les préférences utilisateurs sont détruites) soit on prévoit 12 gazillons de possibilités (barre verticale à droite dans un système d'écriture droite à gauche), le tout avec le moteur standard, avec unico et avec adwaita pour faire bonne mesure.
b) C'est pas moi qui choisi les classes
La force de CSS est que l'on peut décrire une foultitude de classe de façon à faire passer des sélecteurs pour les modifier ou les manipuler si besoin est. Sauf que là les classes sont pour la plupart prédéfinie, et c'est préférable vu que l'on altère plus le contenant que le contenu. Mais du coup on arrive au point ou l'on est coincé dans sa capacité à choisir ou à disposer des classes. le résultat est que l'on se retrouve à créer des sélecteurs en pagaille sur des propriétés.
Vous voulez une image spéciale quand on est grisé une radio box dans un menu d'une fenêtre ? rien de plus simple il suffit de créer le sélecteur
.frame.menu.menuitem.radio:active:insensitive (pour la version cochée)
.frame.menu.menuitem.radio:insensitive (pour la version décochée)
.frame.menu.menuitem.radio:inconsistent:insensitive (pour la version qu'on sait pas encore si elle est cochée ou pas)
Faire un thème pour le moindre widget prend trois pages de déclaration, la seule solution pour ne pas avoir des sélecteurs à rallonge c'est de passer par le nom du widget créé. Par exemple faire une cascade sur NautilusWindow - ah oui mais dans ce cas là on perd l'avantage majeur du CSS : séparation de la logique et du rendu. Pas grave, les thèmes officiels Gnome ne passent quasiment que par des sélecteurs par nom du widget.
c) Il est ou mon DOM ?
Pour pouvoir utiliser les CSS correctement, voire intelligemment il faut connaitre au moins vaguement le DOM, c'est à dire savoir à quel niveau se trouve tel ou tel élément. Dans GTK3 non seulement je ne comprend pas le DOM, mais en plus je ne sais même pas ou se trouve le mien. C'est peut être moi qui suis mal comprenant mais…
J'écris une appli, je fais son css pour elle, j'importe les css GTK3 de base et je tente de respecter le au maximum les préférences utilisateur. Bon à un moment j'ai besoin de permettre à l'utilisateur de naviguer dans les fichiers locaux - pas de soucis j'invoque un widget nautilus et AAAHHH… Mais qu'est-ce qui se passe. Qui est la fenêtre active ? Je suis dans un widget donc ça devrait toujours être moi, mais qu'est-ce qui se passe au niveau du thème ? gnome-application.css fait de l'override forcé du thème mais est-ce que mon widget est bien le fils de mon appli ? Est-ce que les composants de mon widgets sont tous les fils de leur père ? Et si je branche un clef usb après avoir appelé mon widget ?
Et une fenêtre non modale ? C'est une parente de ma fenêtre principale ? Elle hérite des thèmes ? De tous les thèmes ?
Le pire c'est qu'à chaque fois que vous commencer à connaitre (parce que comprendre c'est pas possible) il y a un bug report qui est traité et qui "corrige" un comportement absurde par un autre comportement non moins absurde dans la cascade des styles.
Et puis il y a le SVG. Qui apporte son lot d'élément DOM, mais pas tout à fait comme le DOM SVG html. On pourrait écrire des pages et des pages la dessus.
d) Le CSS change - et GTK3 ?
Déjà sur du pur HTML le W3C se fout sur la gueule en permanence pour savoir ce qui rentre dans CSS et ce qui ne rentre pas. En faisant le choix du CSS GTK3 va se retrouver à plus ou moins long terme à devoir choisir entre deux choses désagréables
1 - suivre le W3C quoi qu'il arrive même si les nouvelles CSS partent dans des directions qui n'apportent rien à un système de thème
2 - maintenir et faire évoluer une version des CSS qui ne sera pas supporté par le W3C.
Ca a déjà commencé. Bonne chance pour faire mumuse avec du z-index ou du float sous GTK3, la taille des éléments est définie en points sans unité précisée (encore que l'em semble être supporté pour les fontes dans les dernières versions - mais c'est pas documenté), et les sélecteurs par nom du widget c'est assez fort…
C'est donc un langage qui ressemble à du CSS, mais qui n'est pas (du tout) du CSS. Ni dans l'esprit (mélange fond forme, DOM tordu, sélection par attributs en pagaille) ni dans la lettre (manque pleins de choses puissantes, subtiles nuances sur les choses restantes).
[^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur
Posté par Kaane . En réponse au journal Conseils aux libristes, 2ème partie: résister à la tentation de la réécriture à partir de zéro. Évalué à 10.
A part le rejet pur et simple, as tu un réel argument pour ne pas utiliser CSS dans GTK ?
Dans l'ordre :
a) C'est pas fait pour ça - Il existe certes des bibliothèques (le plus souvent en javascript) qui permettent de transformer certains éléments CSS en widgets, mais le CSS est un descripteur de style, c'est à dire qu'il sert à normaliser la mise en forme du contenu. S'en servir pour du contenant ne fait pas sens. Cela fait d'autant moins sens que GTK3 possède déjà un moteur de style qui lui est propre - et qu'une partie du fonctionnement interne est inaccessible depuis les CSS, le role de CSS dans le cadre du thème est donc batard :
- Il peut influencer le contenu (via margin , padding, font etc.) mais pas complètement le mettre en forme
- Il peut faire le thème mais pas complètement (il n'y a pas de "retour" en CSS - il faudra donc de toute façon écrire de la logique hors CSS pour le comportement avancé des widgets)
- Il rend le test des applications très complexe : comme les CSS GTK3 ne gèrent pas (encore ? apparament ca ne sera pas fait) l'ajustement automatique de la taille, un élément rendu trop grand par une CSS innapropriée sera tronqué. Comme il est décommandé de créer son propre moteur de theme, on arrive à des situations ou la barre de menu peut avoir été décalé sur le coté alors que vos widgets dans cette barre sont en long. Au final soit on force un thème complet ou presque dans l'appli (mais alors les préférences utilisateurs sont détruites) soit on prévoit 12 gazillons de possibilités (barre verticale à droite dans un système d'écriture droite à gauche), le tout avec le moteur standard, avec unico et avec adwaita pour faire bonne mesure.
b) C'est pas moi qui choisi les classes
La force de CSS est que l'on peut décrire une foultitude de classe de façon à faire passer des sélecteurs pour les modifier ou les manipuler si besoin est. Sauf que là les classes sont pour la plupart prédéfinie, et c'est préférable vu que l'on altère plus le contenant que le contenu. Mais du coup on arrive au point ou l'on est coincé dans sa capacité à choisir ou à disposer des classes. le résultat est que l'on se retrouve à créer des sélecteurs en pagaille sur des propriétés.
Vous voulez une image spéciale quand on est grisé une radio box dans un menu d'une fenêtre ? rien de plus simple il suffit de créer le sélecteur
.frame.menu.menuitem.radio:active:insensitive (pour la version cochée)
.frame.menu.menuitem.radio:insensitive (pour la version décochée)
.frame.menu.menuitem.radio:inconsistent:insensitive (pour la version qu'on sait pas encore si elle est cochée ou pas)
Faire un thème pour le moindre widget prend trois pages de déclaration, la seule solution pour ne pas avoir des sélecteurs à rallonge c'est de passer par le nom du widget créé. Par exemple faire une cascade sur NautilusWindow - ah oui mais dans ce cas là on perd l'avantage majeur du CSS : séparation de la logique et du rendu. Pas grave, les thèmes officiels Gnome ne passent quasiment que par des sélecteurs par nom du widget.
c) Il est ou mon DOM ?
Pour pouvoir utiliser les CSS correctement, voire intelligemment il faut connaitre au moins vaguement le DOM, c'est à dire savoir à quel niveau se trouve tel ou tel élément. Dans GTK3 non seulement je ne comprend pas le DOM, mais en plus je ne sais même pas ou se trouve le mien. C'est peut être moi qui suis mal comprenant mais…
J'écris une appli, je fais son css pour elle, j'importe les css GTK3 de base et je tente de respecter le au maximum les préférences utilisateur. Bon à un moment j'ai besoin de permettre à l'utilisateur de naviguer dans les fichiers locaux - pas de soucis j'invoque un widget nautilus et AAAHHH… Mais qu'est-ce qui se passe. Qui est la fenêtre active ? Je suis dans un widget donc ça devrait toujours être moi, mais qu'est-ce qui se passe au niveau du thème ? gnome-application.css fait de l'override forcé du thème mais est-ce que mon widget est bien le fils de mon appli ? Est-ce que les composants de mon widgets sont tous les fils de leur père ? Et si je branche un clef usb après avoir appelé mon widget ?
Et une fenêtre non modale ? C'est une parente de ma fenêtre principale ? Elle hérite des thèmes ? De tous les thèmes ?
Le pire c'est qu'à chaque fois que vous commencer à connaitre (parce que comprendre c'est pas possible) il y a un bug report qui est traité et qui "corrige" un comportement absurde par un autre comportement non moins absurde dans la cascade des styles.
Et puis il y a le SVG. Qui apporte son lot d'élément DOM, mais pas tout à fait comme le DOM SVG html. On pourrait écrire des pages et des pages la dessus.
d) Le CSS change - et GTK3 ?
Déjà sur du pur HTML le W3C se fout sur la gueule en permanence pour savoir ce qui rentre dans CSS et ce qui ne rentre pas. En faisant le choix du CSS GTK3 va se retrouver à plus ou moins long terme à devoir choisir entre deux choses désagréables
1 - suivre le W3C quoi qu'il arrive même si les nouvelles CSS partent dans des directions qui n'apportent rien à un système de thème
2 - maintenir et faire évoluer une version des CSS qui ne sera pas supporté par le W3C.
Ca a déjà commencé. Bonne chance pour faire mumuse avec du z-index ou du float sous GTK3, la taille des éléments est définie en points sans unité précisée (encore que l'em semble être supporté pour les fontes dans les dernières versions - mais c'est pas documenté), et les sélecteurs par nom du widget c'est assez fort…
C'est donc un langage qui ressemble à du CSS, mais qui n'est pas (du tout) du CSS. Ni dans l'esprit (mélange fond forme, DOM tordu, sélection par attributs en pagaille) ni dans la lettre (manque pleins de choses puissantes, subtiles nuances sur les choses restantes).
Voilà…