c'est intéressant, en tout cas, moi, cela me fait réfléchir.
C'est redondant, je ne sais pas bien. J'ai tendance à penser que ce trio est une abstraction du système de dessin sous jacent. Et qu'à ce titre ce n'est pas vraiment une redondance, ou en tout cas, pas plus redondant que d'avoir GTK et Qt pour faire des applications desktop.
Le cas du bureau himself et de son rôle d'interface avec le sous système et les composants physiques de la machine, est une question à laquelle je n'ai pas d'idée car cela sort complètement de mon scope d’intérêts.
Aujourd'hui ce que je veux c'est développer multi plate forme, simple et testable. Et il s'avère que j'ai trouvé le couplage html/js/css/webservices fort intéressant et fort simple à re déployer quelque soit le système cible.
Bref, j'ai découvert le pattern mvvm, j'ai adoré.
J'ai aussi d'autres considérations, comme, plus c'est bas niveau, plus il faut être qualifié, plus il faut payer. Plus les composants sont concentrés dans une seule entité, moins c'est simple à manipuler arriver à un certain degré de complexité.
Et puis je tentes d'arriver à un véritable develop once run everywhere, qui finalement me parait plus que faisable dans cet environnement de développement et d’exécution.
Il faut aussi prendre en considération un autre fait pas technique du tout pour le coup. Une technologie qui répond à ces besoins, devra nécessairement être portée par l'économie pour se voir injecter des fonds et donc développer des solutions et un haut niveau de qualité (Alors bon des fois sa foire, voir le cas d'IE… C'est la vie).
Hors l'e-commerce, le développement des tablettes, des smartphones, des tv, des lunettes me font penser qu'à termes, c'est ce trio qui restera car de tous les points de vue c'est le plus populaire, grand public.
GTK, je n'ai rien contre, mais voilà, à part quelques applications tels que GIMP, et malgré toute la bonne volonté des développeurs, aujourd'hui c'est une audience somme toute très relative.
Alors ils peuvent si ils le souhaitent continuer en vent d'ouest, c'est un choix qui n'est guère critiquable et je leur souhaites même de réussir.
Au sujet des layouts, widgets ect, comme tu le dis c'est bien développé dans ces environnements. Mais je pense cela concerne plus le bureau, que l'application.
L'application consomme ces widgets, et le bureau doit fournir un moyen à l'application de consommer le widget.
Ce qui effectivement est complètement différent des applications de type site internet avec charte graphique spécifique ect.
On se contentera parfaitement d'une vue webkit après tout ;) Ainsi que d'un moyen de consommer les widgets.
Ta dernière remarque me semble tendancieuse au plus haut point !
Justifiée par l'expérience, mais ce n'est pas la faute des spécifications (enfin pas à ma connaissance) que l'implémentation foire.
Tentons d'en rester aux spécifications, ce sont des rêves d'ingénieurs en cours d'implémentation qui ne demande qu'à être concrétisés.
[^] # Re: javascript, ok.
Posté par maboiteaspam . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 2. Dernière modification le 08 février 2013 à 12:32.
hello,
c'est intéressant, en tout cas, moi, cela me fait réfléchir.
C'est redondant, je ne sais pas bien. J'ai tendance à penser que ce trio est une abstraction du système de dessin sous jacent. Et qu'à ce titre ce n'est pas vraiment une redondance, ou en tout cas, pas plus redondant que d'avoir GTK et Qt pour faire des applications desktop.
Le cas du bureau himself et de son rôle d'interface avec le sous système et les composants physiques de la machine, est une question à laquelle je n'ai pas d'idée car cela sort complètement de mon scope d’intérêts.
Aujourd'hui ce que je veux c'est développer multi plate forme, simple et testable. Et il s'avère que j'ai trouvé le couplage html/js/css/webservices fort intéressant et fort simple à re déployer quelque soit le système cible.
Bref, j'ai découvert le pattern mvvm, j'ai adoré.
J'ai aussi d'autres considérations, comme, plus c'est bas niveau, plus il faut être qualifié, plus il faut payer. Plus les composants sont concentrés dans une seule entité, moins c'est simple à manipuler arriver à un certain degré de complexité.
Et puis je tentes d'arriver à un véritable develop once run everywhere, qui finalement me parait plus que faisable dans cet environnement de développement et d’exécution.
Il faut aussi prendre en considération un autre fait pas technique du tout pour le coup. Une technologie qui répond à ces besoins, devra nécessairement être portée par l'économie pour se voir injecter des fonds et donc développer des solutions et un haut niveau de qualité (Alors bon des fois sa foire, voir le cas d'IE… C'est la vie).
Hors l'e-commerce, le développement des tablettes, des smartphones, des tv, des lunettes me font penser qu'à termes, c'est ce trio qui restera car de tous les points de vue c'est le plus populaire, grand public.
GTK, je n'ai rien contre, mais voilà, à part quelques applications tels que GIMP, et malgré toute la bonne volonté des développeurs, aujourd'hui c'est une audience somme toute très relative.
Alors ils peuvent si ils le souhaitent continuer en vent d'ouest, c'est un choix qui n'est guère critiquable et je leur souhaites même de réussir.
Au sujet des layouts, widgets ect, comme tu le dis c'est bien développé dans ces environnements. Mais je pense cela concerne plus le bureau, que l'application.
L'application consomme ces widgets, et le bureau doit fournir un moyen à l'application de consommer le widget.
Ce qui effectivement est complètement différent des applications de type site internet avec charte graphique spécifique ect.
On se contentera parfaitement d'une vue webkit après tout ;) Ainsi que d'un moyen de consommer les widgets.
Ta dernière remarque me semble tendancieuse au plus haut point !
Justifiée par l'expérience, mais ce n'est pas la faute des spécifications (enfin pas à ma connaissance) que l'implémentation foire.
Tentons d'en rester aux spécifications, ce sont des rêves d'ingénieurs en cours d'implémentation qui ne demande qu'à être concrétisés.
Au plaisir de te lire.