Très bonne question : j'aurais aimé utiliser un binding existant et m'appuyer dessus, mais j'ai finalement choisi de ne pas les faire pour les raisons suivantes :
la lib https://github.com/kropp/kotlin-native-gtk : est intéressante par le fait qu'elle utilise GIR la génération de binding, mais par contre elle garde je trouve une API trop bas niveau à base de CPointers.
la lib https://github.com/Doomsdayrs/kotlinx-gtk offre bien des objets de haut niveau, mais il manque quelques éléments pour lesquels il va à mon avis tomber sur des problèmes avec l'approche par wrappers :
autre exemple, pour glade, ce n'est pas fait, et il le prévoit, mais avec les wrappers et son approche des réinstancier à la volée, il aura : une arbo générée par GtkBuilder, ne fournira que les objets wrapper de top-level, et leurs méthodes passeront leur temps à réinstancier des objets wrapper.
mon objectif était aussi de me faire les dents sur l'interopérabilité avec les libs natives
Pour moi, le binding des fichiers glade est une priorité, parceque c'est ce qui me manque le plus dans le dev GTK actuellement. Or avec des wrappers c'est plus compliqué. Ça laisse le choix entre 1/ réinstancier des objets wrapper sans arrêt, ou bien 2/ créer et maintenir une arbo répliquée d'objets. Je ne trouve ça ni efficace en mémoire, ni élégant, ni pratique en terme d'implémentation. D'où mon expérimentation d'un binding sans objets wrapper.
Effectivement, je comprends qu'on puisse voir ça comme une déclinaison de https://xkcd.com/927/ ;-). Mais ce n'est pas un détail d'implémentation des libs existantes qui me gêne (sinon j'aurais été aider à les compléter / fixer), mais l'approche générale, leur postulat de départ.
Voilà, après, mon plugin gradle de génération de binding glade pourrait sans trop de souci s'adapter à une autre lib de binding.
[^] # Re: Par pure curiosité
Posté par mrlem (site web personnel, Mastodon) . En réponse au journal GTK pour le développeur Kotlin, en mieux. Évalué à 10. Dernière modification le 04 avril 2021 à 06:46.
Très bonne question : j'aurais aimé utiliser un binding existant et m'appuyer dessus, mais j'ai finalement choisi de ne pas les faire pour les raisons suivantes :
la lib https://github.com/kropp/kotlin-native-gtk : est intéressante par le fait qu'elle utilise GIR la génération de binding, mais par contre elle garde je trouve une API trop bas niveau à base de CPointers.
la lib https://github.com/Doomsdayrs/kotlinx-gtk offre bien des objets de haut niveau, mais il manque quelques éléments pour lesquels il va à mon avis tomber sur des problèmes avec l'approche par wrappers :
mon objectif était aussi de me faire les dents sur l'interopérabilité avec les libs natives
Pour moi, le binding des fichiers glade est une priorité, parceque c'est ce qui me manque le plus dans le dev GTK actuellement. Or avec des wrappers c'est plus compliqué. Ça laisse le choix entre 1/ réinstancier des objets wrapper sans arrêt, ou bien 2/ créer et maintenir une arbo répliquée d'objets. Je ne trouve ça ni efficace en mémoire, ni élégant, ni pratique en terme d'implémentation. D'où mon expérimentation d'un binding sans objets wrapper.
Effectivement, je comprends qu'on puisse voir ça comme une déclinaison de https://xkcd.com/927/ ;-). Mais ce n'est pas un détail d'implémentation des libs existantes qui me gêne (sinon j'aurais été aider à les compléter / fixer), mais l'approche générale, leur postulat de départ.
Voilà, après, mon plugin gradle de génération de binding glade pourrait sans trop de souci s'adapter à une autre lib de binding.
J'espère que cela répond à ta question.