Un widget, c'est un objet conceptuel que tu peux décrire dans un langage structuré, aussi compliqué soit il, sans avoir besoin de code. C'est juste un ensemble d'états et de propriétés, auxquelles tu peux lier des actions.
Et une balise c'est juste un espace vide et des indications.
La différence majeure entre une balise et un widget c'est que la balise est "idiote". Une balise image par exemple, si l'image cible n'existe pas - ben j'ai quand même un espace de 240px.400px qui est vide (et dans lequel le navigateur va déssiner uen croix rouge ou un fichier brisé pour me signifier qu'il n'a pas trouvé le contenu)
Une balise est par essence innerte. Si je remplace ma balise image par un champs texte ou par un objet video, la page s'affiche pareil.
Pire si j'agis en javascript pour modifier la cible de ma balise et la remplacer par une cible valide, ben l'image s'affiche.
Un widget c'est de la logique. Si je demande à ouvrir un widget nautilus vers un site FTP inexistant le widget ne sera pas créé. Ca me renverra un message d'erreur. Derrière je ne peux plus changer la cible de mon widget puisqu'il n'a jamais été créé.
Même chose pour certains widgets image. Pas de bras, pas de chocolat.
Mais encore une fois, je ne pense pas que les défauts que tu soulèves remettent en question fondamentalement l'usage de CSS.
Dans le cadre de GTK3 si. On ne pourra jamais utiliser les CSS pour des fonctions de theming dans GTK3 sauf à modifier GTK3 en profondeur. Cette modification consisterait à couper chaque widget en deux : d'un coté la partie graphique/placeholder/rendu et de l'autre la logique. Mais ca revient à créer un autre toolkit complètement.
Dans le cadre d'un nouveau toolkit, la question de la pertinance se pose. Autant les CSS pour la mise en forme du contenu peuvent se justifer, autant pour le contenant ca peut devenir lourd très vite. Le point le plus important pour que les CSS tournent bien est de garder le coté inerte du balisage (pas de retour en CSS => pas de logique). Mais alors il faut cabler chaque bouton, chaque zone de saisie, chaque slider a la mano. En plus il faut aussi se palucher les flux trop gros pour tenir en mémoire d'un coup. Ca allourdi le code, mais c'est faisable (et même déjà fait - jquery-ui, mootools et YUI le prouve.)
_Et là, je ne vois pas où ça pose un problème, ce n'est pas à toi d'ajouter des sélecteurs, ça serait plutôt au moteur de thème de t'exporter des classes _
Il va avoir du mal à choisir les bonnes. A moins d'être très intelligent ET de lire mes pensées. Parceque pour deviner que je veux mettre les mêmes fontes dans le menu et dans les info-bulles mais pas dans les pop-up d'alerte il faut y aller.
Surtout que quand on en arrive à des besoins aussi compliqués que ce que tu décris
Besoins compliqués ? L'exemple que j'ai donné c'est un éditeur de texte, du type de ceux qu'on demande d'écrire en deuxième année d'école d'info. Un éditeur de texte c'est quand même pas compliqué. Un navigateur web ou un logiciel de simulation 3D temps réel je dis pas, mais un éditeur de texte…
[^] # 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é à 3.
Un widget, c'est un objet conceptuel que tu peux décrire dans un langage structuré, aussi compliqué soit il, sans avoir besoin de code. C'est juste un ensemble d'états et de propriétés, auxquelles tu peux lier des actions.
Et une balise c'est juste un espace vide et des indications.
La différence majeure entre une balise et un widget c'est que la balise est "idiote". Une balise image par exemple, si l'image cible n'existe pas - ben j'ai quand même un espace de 240px.400px qui est vide (et dans lequel le navigateur va déssiner uen croix rouge ou un fichier brisé pour me signifier qu'il n'a pas trouvé le contenu)
Une balise est par essence innerte. Si je remplace ma balise image par un champs texte ou par un objet video, la page s'affiche pareil.
Pire si j'agis en javascript pour modifier la cible de ma balise et la remplacer par une cible valide, ben l'image s'affiche.
Un widget c'est de la logique. Si je demande à ouvrir un widget nautilus vers un site FTP inexistant le widget ne sera pas créé. Ca me renverra un message d'erreur. Derrière je ne peux plus changer la cible de mon widget puisqu'il n'a jamais été créé.
Même chose pour certains widgets image. Pas de bras, pas de chocolat.
Mais encore une fois, je ne pense pas que les défauts que tu soulèves remettent en question fondamentalement l'usage de CSS.
Dans le cadre de GTK3 si. On ne pourra jamais utiliser les CSS pour des fonctions de theming dans GTK3 sauf à modifier GTK3 en profondeur. Cette modification consisterait à couper chaque widget en deux : d'un coté la partie graphique/placeholder/rendu et de l'autre la logique. Mais ca revient à créer un autre toolkit complètement.
Dans le cadre d'un nouveau toolkit, la question de la pertinance se pose. Autant les CSS pour la mise en forme du contenu peuvent se justifer, autant pour le contenant ca peut devenir lourd très vite. Le point le plus important pour que les CSS tournent bien est de garder le coté inerte du balisage (pas de retour en CSS => pas de logique). Mais alors il faut cabler chaque bouton, chaque zone de saisie, chaque slider a la mano. En plus il faut aussi se palucher les flux trop gros pour tenir en mémoire d'un coup. Ca allourdi le code, mais c'est faisable (et même déjà fait - jquery-ui, mootools et YUI le prouve.)
_Et là, je ne vois pas où ça pose un problème, ce n'est pas à toi d'ajouter des sélecteurs, ça serait plutôt au moteur de thème de t'exporter des classes _
Il va avoir du mal à choisir les bonnes. A moins d'être très intelligent ET de lire mes pensées. Parceque pour deviner que je veux mettre les mêmes fontes dans le menu et dans les info-bulles mais pas dans les pop-up d'alerte il faut y aller.
Surtout que quand on en arrive à des besoins aussi compliqués que ce que tu décris
Besoins compliqués ? L'exemple que j'ai donné c'est un éditeur de texte, du type de ceux qu'on demande d'écrire en deuxième année d'école d'info. Un éditeur de texte c'est quand même pas compliqué. Un navigateur web ou un logiciel de simulation 3D temps réel je dis pas, mais un éditeur de texte…