Journal GTK pour le développeur Kotlin, en mieux

Posté par mrlem (site web personnel) le 03 avril 2021 à 23:36. Licence CC By‑SA.

Étiquettes :

avr.

2021

Cher Nal,

Il y a bien longtemps que je n'ai pris ma plume pour m'épancher, or me voici avec un petit sujet technique qui me passionne ces derniers jours. S'il peut agrémenter tes journées de liberté réduite.

J'ai été tour à tour développeur C, Web, Java (côté serveur), Java (android), et désormais Kotlin (android). J'aime beaucoup ce langage.

Je suis un utilisateur heureux de GNOME, et donc j'aimerais bien développer des applications GTK. Je sais le faire en C, mais j'aimerais le faire dans le langage qui me plaît : Kotlin. Il existe quelques bindings partiels pour ce langage (un ancien mais plus actif, un actif mais pas complet).

Je me suis donc mis dans la tête de développer des applications Kotlin native pour Linux / GTK. Et pour ce faire, me créer des outils qui rendent ça plus pratique. J'ai donc développé :

un début de binding GTK en Kotlin, avec pour défi de ne pas wrapper les objets natifs dans des objets de plus haut niveau : mes types haut niveau seront donc des alias, leurs méthodes des fonctions d'extension Kotlin
un plugin gradle de génération de binding Glade en Kotlin : le but est d'avoir un truc sympa pour développer (un peu comme le view binding sur Android), où l'on puisse avoir dans notre IDE des accesseurs type-safe pour les widgets définis dans le fichier glade

Tout cela fonctionne à ma grande satisfaction, en mode proof-of-concept pour l'instant, et semble vraiment agréable à l'usage. Il me reste sans doute encore plein d'écueils.

Le code source : https://github.com/mrlem/sample-kotlin-glade

Le futur, pour mon petit projet, c'est essentiellement de m'approcher d'une API complète le plus possible. Pour cela, je suis en train de voir générer tout mon binding via l'introspection GObject (GIR). Et ensuite travailler un peu le packaging.

Voilà.

J'espère cher Nal que tu te portes bien, et que le confinement ne te pèse pas trop. Prends soin de toi.

# Par pure curiosité

Posté par tisaac (Mastodon) le 03 avril 2021 à 23:57. Évalué à 10.

Tu cites deux bindings partiels et tu nous expliques en développer un.

Peux-tu préciser si tu reprends un l'un et/ou l'autre des bindings existants dans ton binding et expliquer ce qui a mené à ton choix ?

Surtout, ne pas tout prendre au sérieux !
- [^] # Re: Par pure curiosité
  
  Posté par mrlem (site web personnel) le 04 avril 2021 à 06:45. É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 :
    - par exemple, Container.getChildren() n'est pas implémenté (cf https://github.com/Doomsdayrs/kotlinx-gtk/blob/main/nativex/src/nativeMain/kotlin/nativex/gtk/widgets/container/Container.kt#L51). Et sauf erreur, quand il voudra l'implémenter, il va devoir soit regénérer à chaque fois des wrappers, soit en garder une liste parallèle qu'il mettra à jour dans tous les autres appels : son approche actuelle semble être de regénérer les objets wrapper sans arrêt (cf https://github.com/Doomsdayrs/kotlinx-gtk/blob/main/nativex/src/nativeMain/kotlin/nativex/gtk/Application.kt#L43), ça ne me paraît pas efficace
    - 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.
  
  J'espère que cela répond à ta question.
# Binding Glade et DSL Kotlin

Posté par YBoy360 (site web personnel) le 04 avril 2021 à 10:17. Évalué à 6. Dernière modification le 04 avril 2021 à 10:18.

Pourquoi ne pas utiliser directement un DSL en Kotlin pour remplacer Glade ? à la TornadoFx par exemple ? Je suis accro aux DSL, mais avec Groovy.

Peut-être que j'ai mal compris ton second point et que c'est ton objectif..

Bravo en tout cas.
- [^] # Re: Binding Glade et DSL Kotlin
  
  Posté par mrlem (site web personnel) le 04 avril 2021 à 10:43. Évalué à 6. Dernière modification le 04 avril 2021 à 10:43.
  
  Les DSL sont vraiment pratiques pour décrire ton UI programmatiquement (les 2 autres bindings en proposent, d'ailleurs), mais ce n'était pas mon objectif premier.
  
  Je voulais bénéficier de l'édition graphique de Glade en priorité : pour pouvoir développer avec IDEA d'un côté et Glade à côté, et que tout se mette à jour tout seul.
  
  Après, je pourrais toujours rajouter un DSL par la suite, mais mes priorités sont Glade et progresser dans la couverture de mon binding GTK (qui est encore ridiculement réduite, j'ai pris plein de raccourcis).
# petite question au passage

Posté par fredoche le 04 avril 2021 à 12:12. Évalué à 5.

Bon courage dans ton projet. Tu sais s'il existe des bindings java corrects , où est ce que ton projet pourrait faire l'affaire dans ce cadre là aussi?
- [^] # Re: petite question au passage
  
  Posté par YBoy360 (site web personnel) le 04 avril 2021 à 14:59. Évalué à 3.
  
  tu peux utiliser SWT (c'est pas exactement ce que tu demandes, c'est agnostique au toolkit de la plateforme), tu as même un binding LWJGL-SWT (Vulkan, OpenGL, CUDA, OpenCL …).
  
  Au passage, pour tout ce qui est graphique, orienté jeux vidéos en Java, LWJGL est pas mal. C'est aussi un outils pour faire des bindings.
  - [^] # Re: petite question au passage
    
    Posté par mrlem (site web personnel) le 04 avril 2021 à 18:20. Évalué à 2. Dernière modification le 04 avril 2021 à 18:20.
    
    SWT et la plateforme RCP, par contre, dans mon souvenir, ils se tordaient un peu les neurones en terme de patterns, des fois ;-). Pour ma part, j'avais fini par le lâcher pour JavaFX.
- [^] # Re: petite question au passage
  
  Posté par mrlem (site web personnel) le 04 avril 2021 à 18:18. Évalué à 3.
  
  Le seul que je connaissais, java-gnome, était un peu moribond, dans mon souvenir (je n'ai pas recreusé, vu que je visais du natif, sans JVM donc).
  
  Mon projet ne peut servir à ça, et n'est pas transposable : il repose sur la cinterop de Kotlin native (en Java, ça passerait par JNI), et pour offrir une API pratique sur les typealias et les extension functions, concepts qui ne sont pas présents en Java (sauf si j'ai raté des choses dans les versions récentes, que je ne suis plus que d'un œil distrait).
  
  Désolé :-P

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.