Journal GTK pour le développeur Kotlin, en mieux

Posté par  (site Web personnel) . Licence CC By‑SA.
Étiquettes :
37
3
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  . É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  (site Web personnel) . Évalué à 10. Dernière modification le 04/04/21 à 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 :

      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  (site Web personnel) . Évalué à 6. Dernière modification le 04/04/21 à 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  (site Web personnel) . Évalué à 6. Dernière modification le 04/04/21 à 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  . É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  (site Web personnel) . É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  (site Web personnel) . Évalué à 2. Dernière modification le 04/04/21 à 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  (site Web personnel) . É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.