Les data bindings de Fyne sont plutot insipire du systeme MVVM ( https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel ). L'idee est de connecter les elements de l'interface a un databinding. Celui-ci peut etre "un proxy"/ViewModel est alterer/combiner les valeurs d'un autre data binding.
Un exemple pour en expliquer le principe, c'est d'avoir un data binding StringWebSocket, qui recupere juste une chaine de charactere via WebSocket. Celui ci peut etre connecte a un JSonString data binding. Imaginons qu'on veut recombiner des champs de ce JSON pour en faire une autre chaine de charactere, du coup on utilise un data binding Sprintf qui prend en parametre les fils de ce data binding JSON. Enfin, on peut connecter cette chaine de charactere a un label qui affichera le resultat de toute cette chaine.
Evidement, si tu veux faire du HTTP, MQTT, ou quelques protocoles que ce soit, tu ne changes que le type du data binding en debut de chaine. Il est possible de coder son propre data binding. Un exemple d'une telle chaine de logique: https://github.com/fynelabs/mqttweather/blob/main/weather.go#L72 .
Pour ce qui est de l'optimisation du framework, c'est l'avantage a mon sens principal des framework en mode "retained" (aucune idee de comment traduire) par rapport a ceux "immediate". En mode "retained", tu as en permanence un etat de ce qui a etait envoye a l'ecran (techniquement sous Linux, tu as interet a te souvenir des 2 dernieres frames) et tu ne mets a jour que ce qui a change entre le buffer que le systeme t'a donne et ce que l'application veut afficher a un moment donnee. Cela veut aussi dire qu'il est plus facile de maintenir un cache qui a du sens, car toutes les donnees deja calcule sont attache aux objets present dans l'interface et leur cycle de vie est gere par le framework graphique de maniere transparente. Bien entendu, si on passe dans une bibliotheque avec une logique "immediate", il faut faire tout cela soi meme.
[^] # Re: Trop simple ?
Posté par cedric . En réponse au journal Interface graphique en Go!. Évalué à 7. Dernière modification le 04 mars 2022 à 22:46.
Les data bindings de Fyne sont plutot insipire du systeme MVVM ( https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel ). L'idee est de connecter les elements de l'interface a un databinding. Celui-ci peut etre "un proxy"/ViewModel est alterer/combiner les valeurs d'un autre data binding.
Un exemple pour en expliquer le principe, c'est d'avoir un data binding StringWebSocket, qui recupere juste une chaine de charactere via WebSocket. Celui ci peut etre connecte a un JSonString data binding. Imaginons qu'on veut recombiner des champs de ce JSON pour en faire une autre chaine de charactere, du coup on utilise un data binding Sprintf qui prend en parametre les fils de ce data binding JSON. Enfin, on peut connecter cette chaine de charactere a un label qui affichera le resultat de toute cette chaine.
Evidement, si tu veux faire du HTTP, MQTT, ou quelques protocoles que ce soit, tu ne changes que le type du data binding en debut de chaine. Il est possible de coder son propre data binding. Un exemple d'une telle chaine de logique: https://github.com/fynelabs/mqttweather/blob/main/weather.go#L72 .
Pour ce qui est de l'optimisation du framework, c'est l'avantage a mon sens principal des framework en mode "retained" (aucune idee de comment traduire) par rapport a ceux "immediate". En mode "retained", tu as en permanence un etat de ce qui a etait envoye a l'ecran (techniquement sous Linux, tu as interet a te souvenir des 2 dernieres frames) et tu ne mets a jour que ce qui a change entre le buffer que le systeme t'a donne et ce que l'application veut afficher a un moment donnee. Cela veut aussi dire qu'il est plus facile de maintenir un cache qui a du sens, car toutes les donnees deja calcule sont attache aux objets present dans l'interface et leur cycle de vie est gere par le framework graphique de maniere transparente. Bien entendu, si on passe dans une bibliotheque avec une logique "immediate", il faut faire tout cela soi meme.