Hormis l'ajout du data binding en plus verbeux que QML
Cet phrase n'a que tres peu de sens. Les data binding sont un mecanisme qui permet de connecter un element graphique a une source de donnees. Le QML est quand a lui un user interface markup language destine a decrire le design et les interactions graphiques de l'application, idealement on ne met pas le code de l'application dans le QML. Ce n'est pas le seul et c'est un concept qui a plusieurs decennie maintenant: https://en.wikipedia.org/wiki/User_interface_markup_language .
L'inconvenient des UIML, c'est qu'il reflete l'intersection entre le canvas graphique utilise et le language auxquel il se connecte, avec des fois une contrainte supplementaire quand ils sont utilise pour definir le theme des widgets, de correspondre a la logique interne des dits widgets. Cela veut dire globalement que chaque UIML est unique et que meme l'introduction de CSS a la GTK, reste un CSS a la GTK qui a peu a voir avec le CSS du web vu que chacun utilise un canvas graphique different. Introduire un nouveau language est tres risque et il faut en avoir le besoin. Les UIML sont principalement utilise quand des interfaces tres customise sont developpe, mais une tres large partie des applications n'en utilisent pas.
L'approche de Fyne et Gio pour est de se baser sur Material Design ( https://material.io/ ). Cela veut dire que la capacite de changer le theme est defini par ce que la specification de material design autorise. Evidement, il y a moins de flexibilite et il n'y a pas besoin de developper un UIML pour ces toolkits. En contre partie, une application aura rapidement un look correct meme quand on n'a pas une grosse equipe pour faire le design.
De plus je ne trouve pas dans la doc la moindre explication sur l'implémentation du moteur de rendu. Il faut utiliser une Image pour faire de l'OpenGL ?
J'avoue ne pas comprendre le sens de cette phrase, mais pour faire simple un framework moderne se doit de faire une abstraction total du driver utilise. C'est une necessite pour la portabilite, mais cela permet aussi de changer completement la logique interne pour s'adapter a de nouvel API graphique.
Le seul avantage, c'est quand la puissance du CSS apporte une valeur ajoutée, par exemple si on veut afficher une typographie à la Wikipédia dans une application.
J'avoue que cette phrase aussi, je n'arrive pas a la comprendre. Le CSS et la typograhie sont des problemes assez orthogonaux. Wikipedia est en plus l'exemple ideal de quand utilise les technos web, car c'est de la pur documentation avec des hyper liens.
[^] # Re: Mais ou est l'innovation ???
Posté par cedric . En réponse au journal Interface graphique en Go!. Évalué à 5.
Cet phrase n'a que tres peu de sens. Les data binding sont un mecanisme qui permet de connecter un element graphique a une source de donnees. Le QML est quand a lui un user interface markup language destine a decrire le design et les interactions graphiques de l'application, idealement on ne met pas le code de l'application dans le QML. Ce n'est pas le seul et c'est un concept qui a plusieurs decennie maintenant: https://en.wikipedia.org/wiki/User_interface_markup_language .
L'inconvenient des UIML, c'est qu'il reflete l'intersection entre le canvas graphique utilise et le language auxquel il se connecte, avec des fois une contrainte supplementaire quand ils sont utilise pour definir le theme des widgets, de correspondre a la logique interne des dits widgets. Cela veut dire globalement que chaque UIML est unique et que meme l'introduction de CSS a la GTK, reste un CSS a la GTK qui a peu a voir avec le CSS du web vu que chacun utilise un canvas graphique different. Introduire un nouveau language est tres risque et il faut en avoir le besoin. Les UIML sont principalement utilise quand des interfaces tres customise sont developpe, mais une tres large partie des applications n'en utilisent pas.
L'approche de Fyne et Gio pour est de se baser sur Material Design ( https://material.io/ ). Cela veut dire que la capacite de changer le theme est defini par ce que la specification de material design autorise. Evidement, il y a moins de flexibilite et il n'y a pas besoin de developper un UIML pour ces toolkits. En contre partie, une application aura rapidement un look correct meme quand on n'a pas une grosse equipe pour faire le design.
J'avoue ne pas comprendre le sens de cette phrase, mais pour faire simple un framework moderne se doit de faire une abstraction total du driver utilise. C'est une necessite pour la portabilite, mais cela permet aussi de changer completement la logique interne pour s'adapter a de nouvel API graphique.
J'avoue que cette phrase aussi, je n'arrive pas a la comprendre. Le CSS et la typograhie sont des problemes assez orthogonaux. Wikipedia est en plus l'exemple ideal de quand utilise les technos web, car c'est de la pur documentation avec des hyper liens.