Je peux comprendre que Mozilla ne propose pas une fonctionnalité de liste blanche pour le moment de JS.
Certes, mauvais exemple, je le reconnais: c'est pas juste de la config, mais bien une fonctionnalité (avancée, de surcroît).
Il faudrait que j'installe firefox pour avoir un meilleur exemple.
Car je pense que tu n'imagines pas comment est conçu une interface graphique logiciellement.
Hum.
Je vais résumer ce dont je me souviens, tu pourras juger:
j'ai un peu joué il y a longtemps (~10 ans) avec Qt et les MFCs, et, longtemps aussi mais moins (~5 ans), avec wxWidgets.
Dans le cas que je me souviens le plus, wx (la 2.9, qui était la bêta de la 3.0, actuelle stable à priori), il y avais 2 solutions: soit placer les coordonnées en dur, soit utiliser des layouts, souvent imbriqués, avec diverses options de poids et autres contraintes.
Dans le cas de la 2nde solution, la plus efficace et la moins chiante, changer la position d'un contrôle se fait très simplement: soit en réorganisant l'ordre des contrôles, soit en insérant un spacer (un placeholder quoi) avant, ou après.
Peu importe la méthode, il est évident que si l'on utilise un GUI pour générer le code, c'est horrible à changer par programme, mais sinon il suffit de changer 2-3 variables, en fonction, soit des coordonnées x,y(et bien sûr dans ce cas, faire attention a ne pas chevaucher un autre contrôle), soit déplacer un objet dans une arborescence. Tout ça me rappelle d'ailleurs que j'avais été obligé de faire une méchante bidouille pour générer la barre de menu principale à partir d'une config, parce que celle-ci, bien qu'ayant une API proche des sous-menu, n'était pas dans la même hiérarchie de classes... souvenirs, souvenirs.
Depuis, il me semble que pas mal de toolkits se basent sur des descriptions d'un fichier extérieur (souvent basé sur un truc proche de HTML, mais ce n'est pas une règle absolue), je peux me tromper.
Jusque la, je parlais de toolkits qui gèrent la totalité de l'aspect graphique de l'application, avec la possibilité de laisser le programmeur prendre la main sur certains contrôles (pour un rendu opengl ou autre). En fait, des frameworks, qui remplacent habituellement la fonction main().
Maintenant, je vais parler un peu de ceux qui sont plus utilisés en conjonction avec des outils dont le rôle principal est d'afficher une fenêtre et de récupérer les évènements (clavier, souris, WM, ...) genre SDL, SFML ou GLFW.
J'ai cherché il y a 2-3 ans un toolkit qui supporte l'injection d'évènements (puisque ceux-ci sont transmis par un autre outil) et qui fasse du rendu uniquement sur une zone initialisée au préalable.
Là, la norme est d'avoir un fichier extérieur qui permette à des non programmeurs de modifier le GUI, justement. Quelques exceptions tout de même utilisaient une approche plus classique, donc celui pour lequel j'avais opté (me souviens plus du nom, pas pertinent de toute façon: vu son implémentation dégueulasse, il ne doit pas être compatible avec GCC >= 5).
Je suppose que depuis il a bien du y avoir plusieurs "révolutions" que je n'ai pas suivies.
mais personnaliser profondément une interface ça n'a rien de trivial.
Tout à fait d'accord. Modifier profondément une interface, c'est complexe.
Changer la position d'un contrôle, ça peut être pénible, je l'admets. Pourquoi?
Parce que ça peut entrer en conflit avec d'autres contrôles. Bien. Maintenant, justement, dans Firefox, il n'y a pas 30000 contrôles, à priori.
Et même si, admettons (il y a peut-être des contrôles cachés après tout, ça fait longtemps que j'ai essayé pour la dernière fois d'avoir un FF confortable à utiliser), changer la position d'un contrôle est une gageure, changer les couleurs d'une interface, ça devrait être simple.
Sauf si, bien entendu, on utilise un toolkit maison bancal (je n'ai jamais utilisé XUL, alors je ne sais pas s'il est bancal, je précise. D'ailleurs, il me semble qu'ils ne l'utilisent plus?). Ou alors qu'on s'en juste fout.
En tout cas, je trouve amusante l'idée qu'il soit préférable d'installer des plugins et des thèmes pour configurer une IHM plutôt que d'intégrer la possibilité de le faire nativement: un bout de code totalement étranger me semble moins recommandé qu'un bout de code fait par des gens qui maîtrisent le logiciel (car ils en sont les éditeurs et sont, en théorie, les mieux placés pour ça) pour éviter les comportements non souhaités.
[^] # Re: questions diverses
Posté par freem . En réponse au journal Firefox Photon: comment l'interface va redevenir ce qu'elle était. Évalué à 3.
Certes, mauvais exemple, je le reconnais: c'est pas juste de la config, mais bien une fonctionnalité (avancée, de surcroît).
Il faudrait que j'installe firefox pour avoir un meilleur exemple.
Hum.
Je vais résumer ce dont je me souviens, tu pourras juger:
j'ai un peu joué il y a longtemps (~10 ans) avec Qt et les MFCs, et, longtemps aussi mais moins (~5 ans), avec wxWidgets.
Dans le cas que je me souviens le plus, wx (la 2.9, qui était la bêta de la 3.0, actuelle stable à priori), il y avais 2 solutions: soit placer les coordonnées en dur, soit utiliser des layouts, souvent imbriqués, avec diverses options de poids et autres contraintes.
Dans le cas de la 2nde solution, la plus efficace et la moins chiante, changer la position d'un contrôle se fait très simplement: soit en réorganisant l'ordre des contrôles, soit en insérant un spacer (un placeholder quoi) avant, ou après.
Peu importe la méthode, il est évident que si l'on utilise un GUI pour générer le code, c'est horrible à changer par programme, mais sinon il suffit de changer 2-3 variables, en fonction, soit des coordonnées x,y(et bien sûr dans ce cas, faire attention a ne pas chevaucher un autre contrôle), soit déplacer un objet dans une arborescence. Tout ça me rappelle d'ailleurs que j'avais été obligé de faire une méchante bidouille pour générer la barre de menu principale à partir d'une config, parce que celle-ci, bien qu'ayant une API proche des sous-menu, n'était pas dans la même hiérarchie de classes... souvenirs, souvenirs.
Depuis, il me semble que pas mal de toolkits se basent sur des descriptions d'un fichier extérieur (souvent basé sur un truc proche de HTML, mais ce n'est pas une règle absolue), je peux me tromper.
Jusque la, je parlais de toolkits qui gèrent la totalité de l'aspect graphique de l'application, avec la possibilité de laisser le programmeur prendre la main sur certains contrôles (pour un rendu opengl ou autre). En fait, des frameworks, qui remplacent habituellement la fonction main().
Maintenant, je vais parler un peu de ceux qui sont plus utilisés en conjonction avec des outils dont le rôle principal est d'afficher une fenêtre et de récupérer les évènements (clavier, souris, WM, ...) genre SDL, SFML ou GLFW.
J'ai cherché il y a 2-3 ans un toolkit qui supporte l'injection d'évènements (puisque ceux-ci sont transmis par un autre outil) et qui fasse du rendu uniquement sur une zone initialisée au préalable.
Là, la norme est d'avoir un fichier extérieur qui permette à des non programmeurs de modifier le GUI, justement. Quelques exceptions tout de même utilisaient une approche plus classique, donc celui pour lequel j'avais opté (me souviens plus du nom, pas pertinent de toute façon: vu son implémentation dégueulasse, il ne doit pas être compatible avec GCC >= 5).
Je suppose que depuis il a bien du y avoir plusieurs "révolutions" que je n'ai pas suivies.
Tout à fait d'accord. Modifier profondément une interface, c'est complexe.
Changer la position d'un contrôle, ça peut être pénible, je l'admets. Pourquoi?
Parce que ça peut entrer en conflit avec d'autres contrôles. Bien. Maintenant, justement, dans Firefox, il n'y a pas 30000 contrôles, à priori.
Et même si, admettons (il y a peut-être des contrôles cachés après tout, ça fait longtemps que j'ai essayé pour la dernière fois d'avoir un FF confortable à utiliser), changer la position d'un contrôle est une gageure, changer les couleurs d'une interface, ça devrait être simple.
Sauf si, bien entendu, on utilise un toolkit maison bancal (je n'ai jamais utilisé XUL, alors je ne sais pas s'il est bancal, je précise. D'ailleurs, il me semble qu'ils ne l'utilisent plus?). Ou alors qu'on s'en juste fout.
En tout cas, je trouve amusante l'idée qu'il soit préférable d'installer des plugins et des thèmes pour configurer une IHM plutôt que d'intégrer la possibilité de le faire nativement: un bout de code totalement étranger me semble moins recommandé qu'un bout de code fait par des gens qui maîtrisent le logiciel (car ils en sont les éditeurs et sont, en théorie, les mieux placés pour ça) pour éviter les comportements non souhaités.