Globalement, j'abonde dans ton sens lorsque tu soulignes que XAML/XUL & consorts ne sont jamais qu'une techno de plus.
Que ce soit adopté ou pas... j'avoue m'en désintéresser
Qu'il manque un véritable outil de développement et de design (type RAD) pour Gnome... je suis aussi d'accord, mais c'est une autre histoire.
En revanche, je pense qu'envisager une alternative à l'implémentation "conventionnelle" des IHM au travers d'interfaces descriptives, quelqu'elles soient, peut constituer un réel avantage dans certains cas, notamment pour :
+ de petits développements
+ l'aspect multiplateforme (moteur de rendu externe à l'application)
+ décorréler l'interface (la vue) du traitement car l'IHM est à mon sens une spécialité à part entière trop souvent négligée dans une application.
Cette approche permet entre autres :
+ de ne pas (ou peu) se soucier du rendu de l'interface délégué à un moteur "externe"
+ d'autoriser plus de souplesse tant au niveau du développement (ressources externes au code proprement dit) qu'à l'utilisation (possibilité de fournir une description "alternative" : look-n-feel, ergonomie adaptée/adaptable...)
[^] # IHM et interfaces descriptives
Posté par Quzqo . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 2.
Que ce soit adopté ou pas... j'avoue m'en désintéresser
Qu'il manque un véritable outil de développement et de design (type RAD) pour Gnome... je suis aussi d'accord, mais c'est une autre histoire.
En revanche, je pense qu'envisager une alternative à l'implémentation "conventionnelle" des IHM au travers d'interfaces descriptives, quelqu'elles soient, peut constituer un réel avantage dans certains cas, notamment pour :
+ de petits développements
+ l'aspect multiplateforme (moteur de rendu externe à l'application)
+ décorréler l'interface (la vue) du traitement car l'IHM est à mon sens une spécialité à part entière trop souvent négligée dans une application.
Cette approche permet entre autres :
+ de ne pas (ou peu) se soucier du rendu de l'interface délégué à un moteur "externe"
+ d'autoriser plus de souplesse tant au niveau du développement (ressources externes au code proprement dit) qu'à l'utilisation (possibilité de fournir une description "alternative" : look-n-feel, ergonomie adaptée/adaptable...)