Cher journal,
J'ai appris sur le forum de GNOME que le projet gtkmm est à la recherche de nouvelles forces pour maintenir le projet (gtkmm est un binding C++ pour les interfaces graphiques Gtk).
Kjell Ahlstedt, qui fait partie actuellement de l'équipe de maintenance, écrit dans le bug gtkmm/#110:
I will not continue forever with maintenance of gtkmm and other *mm modules.
Unless someone else continues the work, glibmm, gtkmm and other modules will
be abandoned in a near future.
Ce que je traduirai librement par:
Je ne vais pas continuer à jamais avec la maintenance de gtkmm et des autres modules *mm. À moins que d'autres continuent le travaille, glibmm, gtkmm et les autres modules sont bientôt être abandonnés.
Personnellement, je ne connais pas assez Gtk ni le C++ pour me lancer sur ce genre de projets.
J'écris donc ce journal pour transmettre l'information et je croise les doigts pour que quelqu'un puisse reprendre le flambeau 😊
Si jamais gtkmm et les autres modules *mm tombent vraiment à l'abandon, il existe aussi le projet cppgir qui permet d'automatiser la création des binding entre Gtk et C++ grâce à l'utilisation de GObject Instrospection.
Je ne l'ai jamais testé ni utilisé, je ne sais donc pas s'il peut remplacer complètement gtkmm et consort. Je pense qu'il est intéressant, car il essaie d'utiliser l'outil GNOME officiel pour faire les nouveaux binding depuis la version 3 de Gtk.
# C'était prévu
Posté par Philippe F (site web personnel) . Évalué à 10. Dernière modification le 06 mars 2022 à 15:35.
Quand je discutais il y a une bonne vingtaine d'année avec Guillaume Laurent, l'un des ex-mainteneurs de gtkmm, il m'avait expliqué que le projet n'avait pas de futur. Ce qu'il avait identifié, en tant que mainteneur, c'est que la charge de travail pour générer des bindings à la main était énorme, et que Gtk se prêtait mal à cet exercice. L'autre facteur, c'était le manque d'intérêt de la communauté pour un binding C++ vers Gtk. Les développeurs étaient très majoritairement heureux avec le Gtk en C. En tant que fan de C++, il s'était tourné vers Qt, à rebours de tout le monde à l'époque (chacun restait dans son camp, Qt/KDE vs Gnome/Gtk).
Par curiosité, j'ai cliqué sur les projets listés sur la page de gtkmm pour voir ce qu'il en était aujourd'hui. Je tombe en très grande partie sur des pages qui n'existent plus, des dépôts sous CVS sous sourceforge qui n'ont jamais été migrés, des dépôts valides mais sans commits depuis 15 ans, ou 10 ans pour certains.
Il reste quelques survivants néanmoins: inkscape, K-3D (pas complètement actif mais pas mort quand même), gobby en mode maintenance, gparted qui a l'air relativement actif.
Il y a surement d'autres projets non listés. Par contre, vu le petit nombre de projet actifs, on peut s'attendre à ce qu'il n'y aie pas grand monde pour reprendre le flambeau.
Je me demandais ce que ça me faisait, 15 ans plus tard, de constater que ma vision sur Qt et Gtkmm était juste. Il y a une vague petite satisfaction d'avoir eu raison, mais surtout, c'est juste dommage pour ces projets dont certains avaient l'air sympatique. Je doute que gtkmm a lui seul soit la raison de cette désaffection, mais ça reste dommage quand même. Après … c'est la vie, des projets logiciel libre, il en nait et meurt tous les jours.
Tiens d'ailleurs, le projet de Guillaume Laurent a-t-il survécu ? Mais oui, RoseGarden est toujours sur sourceforge, et visiblement toujours actif !
[^] # Re: C'était prévu
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 06 mars 2022 à 17:08.
Tu voulais pas dire « c'était couru (d'avance) » ou « c'était prévisible » ? Parce-que si c'était prévu (au sens que c'est le plan), il n'y aurait pas de raison de chercher de mainteneur. :-)
Sinon, je me demandais qui l'utilisait et quelle est la difficulté (le vrai souci) et tu as répondu à mes questions. Merci beaucoup pour ton éclairage. :-|
Bon, les quelques usagers restant/actifs sont quand même assez important pour que ça ne meurt pas …avant qu'il y ait la migration vers autre chose.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: C'était prévu
Posté par swilmet . Évalué à 3. Dernière modification le 08 mars 2022 à 11:42.
Pour ajouter des infos, créer un projet C++ en GTK demande d'avoir les bindings C++ pour une partie de la GLib aussi (glibmm). Quand une fonction de GTK prend en paramètre ou retourne une structure de donnée définie dans la GLib, il faut que ce soit utilisable de manière pratique en C++ aussi.
À la fois GTK 2, 3 et 4 dépendent de la GLib 2. Au plus on avance dans les versions de GTK, au plus on dépend de fonctionnalités plus récentes de la GLib (dont des bindings C++ sont donc requis).
Mais, GTK 2 et 3 n'évoluent plus. Ces versions de GTK ne dépendent pas des toutes dernières nouveautés de la GLib. Et je suppose que gtkmm, glibmm, etc couvrent assez bien toutes les API (en ce qui concerne GTK 2 et 3).
En ce qui concerne GTK 4, c'est bien sûr une autre histoire.
Ce qui veut dire que les projets C++ utilisant GTK 2 ou 3 ne se sentent pas forcés d'aider à la maintenance de gtkmm etc (chose qui peut-être ne leur sera jamais utile si le projet ne migre pas à GTK 4).
Il y a aussi Ardour comme gros projet en C++ et GTK (mais c'est du GTK 2).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.