Qui a parlé de transformer le CSS en widget ? Les widgets jouent un peu le rôle des balises HTML, et le CSS sert à définir le style.
Non.
En HTML on a trois choses : le balisage, le contenu et la selection. Un widgets a en plus des états, des relations et de façon générale toute uen logique cablée qui influence son comportement. C'est pour celà qu'en CSS gnome on passe son temps à définir des dizaines de comportement CSS en fonction de tout une palanquée d'attributs.
Pour que les paradigmes se recoupent il faudrait que GTK3 fonctionne comme javascript, c'est à dire qu'il utilise les mêmes sélecteurs CSS que la mise en forme. (Et ca ne serait pas une bonne idée du tout.)
_Je n'appelle pas ça influencer le contenu, c'est justement le mettre en forme. _
Mais la mise en forme ca influence le contenu. Si l'utilisateur a décidé de mettre la barre d'outil en vertical à gauche et de tripler la taille du texte j'ai le choix entre mettre à la poubelle ses préférences (ce qui est la solution retenue par toutes les applis GTK3 que j'ai pu croiser) ou prendre le risque que mon interface explose.
Pour bien faire il faudrait une fois de plus que le rendu CSS GTK3 soit fluide, et que l'on dispose d'un retour sur l'interface du même type que celui dont on dispose en javascript - et qui permette de récupérer, d'analyser et de modifier la mise en page à la volée. Gnome-shell permet (un peu) ce genre de choses, mais une appli standard ne dispose pas de framework standard pour effectuer ces opérations. On y va à coup d'introspection et on prie.
_ Le fait que tu ne choisisses pas les classes n'a rien à voir avec l'utilisation de CSS, mais plutôt avec le fait que les widgets sont déjà définis et que GTK3 n'est pas un toolkit modulaire permettant d'ajouter des widgets. Ce que tu critiques est je pense voulu. Une classe par widgets, pour assurer l'uniformité du thème._
Mais je veux pas ajouter de widgets, je veux simplement une méthode simple qui me permette d'utiliser mes bouttons dans les partie spécifiques de mon appli et les bouttons standards dans les parties génériques.
Un exemple tout con : je veux faire un éditeur de texte dans lequel j'ai un arbre de navigation et une fenêtre de saisie d'un certain type pour les langages procéduraux et un autre arbre de navigation avec une autre fenêtre de saisie pour les langages fonctionnels. De plus je rajoute ou j'enlève des éléments à mon arbre en fonction du fait que le langae soit objet ou non. A cela j'ajoute une fenêtre de saisie en dessous pour l'accès console et une autre fenêtre en affichage seul pour la sortie de compilation/le debug.
Si je pouvais créer des classes ca prendrait 10 secondes à faire, mais comme je ne peux pas je suis OBLIGE de me trimballer des sélecteurs de 100 pieds de long pour distinguer entre mes différents éléments qui déscendent tous du même widget. Et si je veux créer une fenêtre en double pan pour les diffs et les merge ? Encore un selecteur. Et si je veux que l'utilisateur puisse détacher la fenêtre de debug pour la passer sur l'écran d'à coté ? Encore un autre sélecteur. Et dans chaque selecteur je refais TOUTE la CSS spécifique à l'élément. Donc le jour ou je veux changer le comportement de mon élément il faut que j'aille modifier mes CSS à 14 endroits différents. C'est EXACTEMENT ce que le CSS est supposé éviter.
_ Pourquoi veut tu un DOM ?_
Déjà parceque ca me permet de savoir quels éléments vont hériter de mes modifs CSS et quels sont ceux qui vont passer au travers. C'est fondamental quand on fait un thème ou une interface de savoir ce qui va être impacté. Je veux que mon boutton "fermer" soit en rouge violent sur la fenêtre qu'il ne faut surtout pas fermer a moins d'être sur à 100% de son coup, par contre je ne veux pas qu'il soit en rouge violent au niveau de la fenêtre d'aide qui peut elle être fermée quand on veut. Le DOM est ce qui me permet de savoir QUEL comportement je modifie quand je n'ai pas envie de les modifier tous.
Ce que tu demandes, c'est ce que GTK3 ne te fournit pas, mais encore une fois, non parce qu'il utilise CSS, mais parce que ce n'est pas son but.
Je te rassure, GTK3 fourni tout un tas d'outils qui permettent de faire des modifications d'aspect en fonction du fonctionnel sans que ca n'impacte l'ensemble des widgets du même nom sur toute l'appli. Sinon ca ne servirait pas à grand chose. On ne peut juste pas accéder simplement a ces fonctions depuis les CSS parceque les deux méthodes d'accès (par classe spécifique utilisateur et par parcours de l'arbre DOM) ne sont pas implémentées correctement.
Tu ne peux pas faire de manipulation complexe, de créer des thèmes par widgets, etc, etc, mais c'est assumé.
Assumé est un bien grand mot. Ils (les devs Gnome) disent qu'il ne faut pas créer de moteurs de thème, qu'il ne faut pas faire d'introspection pour des raisons de décorations, qu'il ne faut pas faire des sous groupements de widgets par fonction etc. Tu dois tout pouvoir faire avec du SVG et des CSS. Alors du coup tu essayes, tu y arrives pas et tu vas lire leur code poru savoir comment eux ils ont fait. Réponse : Ils ont créés des moteurs de thème custom dans lesquels il font des sous groupes de widgets, ils font de l'introspection à tire larigo, ils utilisent du png pour les images sans arrêt….
Sur Gnome-Shell ? On va carrément chercher un interpreteur ECMASCRIPT. Sur Nautilus ? On créé un widget custom par fonction et par sous fonction.
Si même eux n'arrivent pas à respecter leur truc sur des aspect fondamentaux du produit, je vois pas comment moi j'arriverai à faire quelque chose de propre.
En somme tu râles parce que GTK3 n'est pas aussi puissant que tu le souhaiterais
Non je rale parceque je me prend tous les inconvennients d'un sucre syntaxique assez lourd (les objest CSS) sans aucun des avantages. Pas de réutilisabilité au sein de mon appli, pas de selecteur simple, pas de DOM donc pas d'éléments cibles facile à atteindre. A chaque instant ou j'utilise les CSS GTK3 j'ai l'impression qu'on m'a donné une perceuse pour planter des clous. C'est proche du besoin en effet, mais makgré tout complètement à coté de la plaque.
GTK3 assume l'utilisation d'un sous-ensemble de CSS, je ne vois pas en quoi c'est un problème en soi tant que c'est documenté.
Alors déjà le tant que c'est documenté on y est pas encore.
Ensuite comme les CSS ne sont pas respectés par l'équipe Gnome elle-même on a des glitch dans tous les sens (variables en fonction du moteur de style utilisé) - donc même documenté il y aurait des chausse-trappes partout.
Et pour finir utiliser les CSS parceque "c'est trop cool, tout le monde connait, tout le monde sait s'en servir" avant de sortir une version limité autant au niveau des éléments, que des attributs et avec en prime un format différent pour les valeurs acceptable c'est idiot.
Sélectionner mes éléments avec des elem:active:insensitive:hoover:focus ca n'est intuitif pour aucun dev CSS. Ne pas pouvoir créer des classes et les réorganiser ca n'est intuitif pour aucun dev CSS.
Quitte à faire un autre langage, autant en faire vraiment un autre - là cet hybride est juste un piège qui va faire croire aux devs qu'ils peuvent rentrer dans le code directement (et qui va les accueillir avec un grand coup de batte de base-ball dans les gencives).
Pour résumer ton commentaire, tu dis que GTK3 ne répond pas à tout tes besoins et ne te permet pas une aussi grande souplesse qu'un site web
Je n'ai pas dit ça du tout. J'ai dit que GTK3 CSS ne permet pas de faire du GTK3. GTK3 et CSS sont sur deux paradigmes différents, ils ne peuvent totu simplement pas travailler ensemble de façon efficace pour faire du theming. Ca n'est juste pas possible. L'un des deux doit évoluer pour pouvoir dialoguer pleinement avec l'autre. Idéalement GTK3 devrait évoluer pour coller parfaitement au CSS du W3C (ou même à un sous ensemble de ces CSS) puisque c'est le but avoué de tout ce tintouin. Sauf que bien sur, à chaque fois qu'il y a un soucis c'est soit une verrue, soit une modif des specs CSS GTK3.
en quoi ne pas utiliser CSS, (GTK2 par exemple) améliorerait les choses que tu ne peux pas faire ?
Ben je n'utilise plus correctement CSS en GTK3 (et je ne m'en porte que mieux), l'utilisateur devrait déjà être content de conserver sa déco de fenêtre intacte. Je fais mes déco dans des scope volatils au moment du refresh. Mes feuilles css redéfinissent à peut près tous les widgets demon appli (et elles sont elles mêmes écrasées par les css dynamiques des scope précédamment évoqué). Pour tous les trucs un peu complexe (genre un slider qui est légèrement plus gros ou plus rouge que les autres) je donne un grand de coup de hache dans le moteur de thème etc.
C'est moche hein ? Mais tu sais le pire ? Tout le monde fait comme moi, même au sein du projet Gnome.
[^] # 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é à 7.
Qui a parlé de transformer le CSS en widget ?
Les widgets jouent un peu le rôle des balises HTML, et le CSS sert à définir le style.
Non.
En HTML on a trois choses : le balisage, le contenu et la selection. Un widgets a en plus des états, des relations et de façon générale toute uen logique cablée qui influence son comportement. C'est pour celà qu'en CSS gnome on passe son temps à définir des dizaines de comportement CSS en fonction de tout une palanquée d'attributs.
Pour que les paradigmes se recoupent il faudrait que GTK3 fonctionne comme javascript, c'est à dire qu'il utilise les mêmes sélecteurs CSS que la mise en forme. (Et ca ne serait pas une bonne idée du tout.)
_Je n'appelle pas ça influencer le contenu, c'est justement le mettre en forme. _
Mais la mise en forme ca influence le contenu. Si l'utilisateur a décidé de mettre la barre d'outil en vertical à gauche et de tripler la taille du texte j'ai le choix entre mettre à la poubelle ses préférences (ce qui est la solution retenue par toutes les applis GTK3 que j'ai pu croiser) ou prendre le risque que mon interface explose.
Pour bien faire il faudrait une fois de plus que le rendu CSS GTK3 soit fluide, et que l'on dispose d'un retour sur l'interface du même type que celui dont on dispose en javascript - et qui permette de récupérer, d'analyser et de modifier la mise en page à la volée. Gnome-shell permet (un peu) ce genre de choses, mais une appli standard ne dispose pas de framework standard pour effectuer ces opérations. On y va à coup d'introspection et on prie.
_ Le fait que tu ne choisisses pas les classes n'a rien à voir avec l'utilisation de CSS, mais plutôt avec le fait que les widgets sont déjà définis et que GTK3 n'est pas un toolkit modulaire permettant d'ajouter des widgets. Ce que tu critiques est je pense voulu. Une classe par widgets, pour assurer l'uniformité du thème._
Mais je veux pas ajouter de widgets, je veux simplement une méthode simple qui me permette d'utiliser mes bouttons dans les partie spécifiques de mon appli et les bouttons standards dans les parties génériques.
Un exemple tout con : je veux faire un éditeur de texte dans lequel j'ai un arbre de navigation et une fenêtre de saisie d'un certain type pour les langages procéduraux et un autre arbre de navigation avec une autre fenêtre de saisie pour les langages fonctionnels. De plus je rajoute ou j'enlève des éléments à mon arbre en fonction du fait que le langae soit objet ou non. A cela j'ajoute une fenêtre de saisie en dessous pour l'accès console et une autre fenêtre en affichage seul pour la sortie de compilation/le debug.
Si je pouvais créer des classes ca prendrait 10 secondes à faire, mais comme je ne peux pas je suis OBLIGE de me trimballer des sélecteurs de 100 pieds de long pour distinguer entre mes différents éléments qui déscendent tous du même widget. Et si je veux créer une fenêtre en double pan pour les diffs et les merge ? Encore un selecteur. Et si je veux que l'utilisateur puisse détacher la fenêtre de debug pour la passer sur l'écran d'à coté ? Encore un autre sélecteur. Et dans chaque selecteur je refais TOUTE la CSS spécifique à l'élément. Donc le jour ou je veux changer le comportement de mon élément il faut que j'aille modifier mes CSS à 14 endroits différents. C'est EXACTEMENT ce que le CSS est supposé éviter.
_ Pourquoi veut tu un DOM ?_
Déjà parceque ca me permet de savoir quels éléments vont hériter de mes modifs CSS et quels sont ceux qui vont passer au travers. C'est fondamental quand on fait un thème ou une interface de savoir ce qui va être impacté. Je veux que mon boutton "fermer" soit en rouge violent sur la fenêtre qu'il ne faut surtout pas fermer a moins d'être sur à 100% de son coup, par contre je ne veux pas qu'il soit en rouge violent au niveau de la fenêtre d'aide qui peut elle être fermée quand on veut. Le DOM est ce qui me permet de savoir QUEL comportement je modifie quand je n'ai pas envie de les modifier tous.
Ce que tu demandes, c'est ce que GTK3 ne te fournit pas, mais encore une fois, non parce qu'il utilise CSS, mais parce que ce n'est pas son but.
Je te rassure, GTK3 fourni tout un tas d'outils qui permettent de faire des modifications d'aspect en fonction du fonctionnel sans que ca n'impacte l'ensemble des widgets du même nom sur toute l'appli. Sinon ca ne servirait pas à grand chose. On ne peut juste pas accéder simplement a ces fonctions depuis les CSS parceque les deux méthodes d'accès (par classe spécifique utilisateur et par parcours de l'arbre DOM) ne sont pas implémentées correctement.
Tu ne peux pas faire de manipulation complexe, de créer des thèmes par widgets, etc, etc, mais c'est assumé.
Assumé est un bien grand mot. Ils (les devs Gnome) disent qu'il ne faut pas créer de moteurs de thème, qu'il ne faut pas faire d'introspection pour des raisons de décorations, qu'il ne faut pas faire des sous groupements de widgets par fonction etc. Tu dois tout pouvoir faire avec du SVG et des CSS. Alors du coup tu essayes, tu y arrives pas et tu vas lire leur code poru savoir comment eux ils ont fait. Réponse : Ils ont créés des moteurs de thème custom dans lesquels il font des sous groupes de widgets, ils font de l'introspection à tire larigo, ils utilisent du png pour les images sans arrêt….
Sur Gnome-Shell ? On va carrément chercher un interpreteur ECMASCRIPT. Sur Nautilus ? On créé un widget custom par fonction et par sous fonction.
Si même eux n'arrivent pas à respecter leur truc sur des aspect fondamentaux du produit, je vois pas comment moi j'arriverai à faire quelque chose de propre.
En somme tu râles parce que GTK3 n'est pas aussi puissant que tu le souhaiterais
Non je rale parceque je me prend tous les inconvennients d'un sucre syntaxique assez lourd (les objest CSS) sans aucun des avantages. Pas de réutilisabilité au sein de mon appli, pas de selecteur simple, pas de DOM donc pas d'éléments cibles facile à atteindre. A chaque instant ou j'utilise les CSS GTK3 j'ai l'impression qu'on m'a donné une perceuse pour planter des clous. C'est proche du besoin en effet, mais makgré tout complètement à coté de la plaque.
GTK3 assume l'utilisation d'un sous-ensemble de CSS, je ne vois pas en quoi c'est un problème en soi tant que c'est documenté.
Alors déjà le tant que c'est documenté on y est pas encore.
Ensuite comme les CSS ne sont pas respectés par l'équipe Gnome elle-même on a des glitch dans tous les sens (variables en fonction du moteur de style utilisé) - donc même documenté il y aurait des chausse-trappes partout.
Et pour finir utiliser les CSS parceque "c'est trop cool, tout le monde connait, tout le monde sait s'en servir" avant de sortir une version limité autant au niveau des éléments, que des attributs et avec en prime un format différent pour les valeurs acceptable c'est idiot.
Sélectionner mes éléments avec des elem:active:insensitive:hoover:focus ca n'est intuitif pour aucun dev CSS. Ne pas pouvoir créer des classes et les réorganiser ca n'est intuitif pour aucun dev CSS.
Quitte à faire un autre langage, autant en faire vraiment un autre - là cet hybride est juste un piège qui va faire croire aux devs qu'ils peuvent rentrer dans le code directement (et qui va les accueillir avec un grand coup de batte de base-ball dans les gencives).
Pour résumer ton commentaire, tu dis que GTK3 ne répond pas à tout tes besoins et ne te permet pas une aussi grande souplesse qu'un site web
Je n'ai pas dit ça du tout. J'ai dit que GTK3 CSS ne permet pas de faire du GTK3. GTK3 et CSS sont sur deux paradigmes différents, ils ne peuvent totu simplement pas travailler ensemble de façon efficace pour faire du theming. Ca n'est juste pas possible. L'un des deux doit évoluer pour pouvoir dialoguer pleinement avec l'autre. Idéalement GTK3 devrait évoluer pour coller parfaitement au CSS du W3C (ou même à un sous ensemble de ces CSS) puisque c'est le but avoué de tout ce tintouin. Sauf que bien sur, à chaque fois qu'il y a un soucis c'est soit une verrue, soit une modif des specs CSS GTK3.
en quoi ne pas utiliser CSS, (GTK2 par exemple) améliorerait les choses que tu ne peux pas faire ?
Ben je n'utilise plus correctement CSS en GTK3 (et je ne m'en porte que mieux), l'utilisateur devrait déjà être content de conserver sa déco de fenêtre intacte. Je fais mes déco dans des scope volatils au moment du refresh. Mes feuilles css redéfinissent à peut près tous les widgets demon appli (et elles sont elles mêmes écrasées par les css dynamiques des scope précédamment évoqué). Pour tous les trucs un peu complexe (genre un slider qui est légèrement plus gros ou plus rouge que les autres) je donne un grand de coup de hache dans le moteur de thème etc.
C'est moche hein ? Mais tu sais le pire ? Tout le monde fait comme moi, même au sein du projet Gnome.