C'est effectivement ce qu'aiment bien répéter les gens qui n'iront pas faire le portage eux-même, ou qui ont juste porté des logiciels simplistes avec 3 fenêtres (ce n'est pas un reproche, il y a de la place pour les logiciels simples, et c'est d'ailleurs la majorité des logiciels GNOME; néanmoins GIMP n'est pas de cette catégorie).
Perso je ne sais pas encore, puisque je n'ai pas même essayé. Néanmoins j'ai déjà jeté un œil (rapide) sur le document de migration GTK+3 vers GTK4. On notera déjà la longueur du document. C'est pas juste une page A4! Mais bon passons la frayeur initiale, et regardons un peu en détail.
Puisque je viens de passer du temps sur le port des actions de l'ancien paradigme (GTK+2) au "nouveau" (GTK+3), voyons donc si quelque chose change encore. Je découvre donc que GtkMenu, GtkMenuBar et GtkMenuItem sont retirés 😱. Pour avoir passé plus de 2 mois à être passé des anciennes GtkAction et GtkUIManager et compagnie vers GAction, GMenuModel, GtkMenu, GtkMenuItem, etc. (c'est le sujet de mon tweet/toot que tout le monde recopie ces derniers jours!), découvrir que la moitié des API utilisées par mon travail de port a déjà été retirée, ça me met pas en joie!
En gros, dans GTK, entre la version 2 et 3, on nous fait passer d'une logique à une nouvelle. Et la nouvelle logique est elle-même à moitié supprimée dès le passage à la version 4. Alors heureusement la moitié du travail est encore valide (GAction, GMenuModel, etc.) mais bon... j'aurais bien aimé que ce soit l'entièreté et qu'on change pas de paradigme tous les 4 matins!
Et encore, je dis que j'ai passé plus de 2 mois, mais mon co-mainteneur avait déjà commencé en partie ce travail y a quelques années; et même maintenant c'est pas "totalement" fini (on a tellement d'usages avancés des actions que je trouve encore constamment des bugs à corriger et des fonctionnalités à réimplémenter pour éviter les régressions avec ce nouveau code), même si on va considérer que ça l'est d'un point de vue "le cœur du travail est fait".
Notons qu'en fait, on peut déjà faire pas mal de trucs sans GtkMenu* même dans GTK+3, car GTK est capable de générer des menus de lui-même à partir d'un modèle (dans certains cas), mais la raison pour laquelle on continue d'écrire nos propres menus (en plus du fait qu'il y avait des parties de GIMP où on n'avait pas le choix de toutes façons) est que GTK a choisi de simplifier son usage des menus. Par exemple les menus créés par l'API de base ne peuvent plus avoir de tooltips (info-bulles), ce qui est malheureusement connu et la proposition d'ajout fut refusée.
Pour un logiciel complexe comme GIMP avec des dizaines de filtres et d'actions complexe, la possibilité d'avoir des info-bulles détaillant un peu plus ce que fait une action ou un filtre au nom scientifique/technique parfois un peu barbare me paraît comme une fonctionnalité importante que je voulais pas perdre dans nos menus.
De manière générale, nos menus sont assez avancés, avec des info-bulles, parfois des couleurs, des labels changeants, des petites icônes et des prévisualisations d'image, etc.
Enfin bon, le premier truc, c'est donc que j'ai quand même un peu l'impression d'avoir à réimplémenter dans GIMP des trucs (qui existaient avant) parce que le toolkit juge cela non nécessaire désormais et a retiré la fonctionnalité. D'ailleurs ce sont aussi des remarques que je peux faire avec Wayland et les "portails" où on fait des aller-retours entre les recommandations de tout faire en portail dorénavant et la constatation que l'on y perd des fonctionnalités, dont notamment la gestion d'espaces de couleurs, ce qui est problématique pour un logiciel d'imagerie!
C'est d'ailleurs un constat que m'ont fait explicitement plusieurs des développeurs principaux de GTK. Ce dernier se focalise désormais sur les applications simples. À nous de réimplémenter les usages d'UI complexes.
Bon c'est juste un point. Mais de manière générale, quand je lis cette page en diagonale, à peu près tous les points de cette liste nous touchent:
Drag'n drop? Massivement utilisé un peu partout! On peut quasiment tout glisser-déposer dans GIMP! Des images, des couleurs, des patterns...
Les signaux d'évènements? Massivement utilisés! On a plein de widgets personnalisés, et notre canevas est un florilège de tout ce qui est faisable en terme de gestion d'évènements.
Ce n'est pas un remplacement en search-and-replace dont il est question ici puisque maintenant il faudra remplacer chaque cas par une fonction spécifique en fonction de la sous-classe réelle. C'est donc plus de 900 cas à gérer en cas par cas.
Encore une fois, le document indique que le remplacement doit se faire au cas par cas (on ne peut pas juste faire un remplacement massif).
Ne parlons pas (ah si en fait!) de GtkTreeModel et GtkTreeView qu'on nous conseille de porter à GtkListView et GtkColumnView. Bon le bon point là (contrairement aux points précédents), c'est que c'est pas encore retiré, seulement déprécié depuis GTK 4.10 (on pourrait donc décider de ne pas changer ça immédiatement, mais alors on va encore se farcir des centaines de warnings à la compilation). Alors GtkTreeView, c'est une API absolument horrible, y a pas à dire. Très complète et puissante, mais vraiment dure à utiliser conceptuellement. J'ai un peu une relation amour-haine avec. Néanmoins les faits est qu'on utilise cela massivement dans GIMP. Rien qu'à l'idée de réimplementer nos dockables d'items, par exemple la liste des calques, me donne mal à la tête. Notre GUI de liste de calque est l'une des plus avancées et complètes que vous pourriez imaginer au niveau fonctionnalités. On peut un peu tout faire avec du glisser-déposer, y a des fonctions spéciales un peu partout avec des clics gauche, droit, milieu, avec des modificateurs, etc. Ça a vraiment été rendu super puissant pour les besoins et l'efficacité des utilisateurs avancés.
Enfin bon, un énorme chantier en perspective, celui-là.
Etc. Etc. Etc.
En fait je suis pas sûr s'il y a même un seul point de cette liste qui ne nous concerne pas (j'en ai juste cité quelques uns évidents au hasard, mais ensuite il convient de voir chaque point en détail).
GIMP utilise quasiment tous les anciens widgets et probablement tous les usages avancés de ces widgets (dont beaucoup ont été conçus pour et peut-être par les développeurs de GIMP à travers les âges). Le problème, c'est qu'on est peut-être aussi les seuls à les utiliser, et probablement, cela pose problème car ceux qui travaillent sur des interfaces plus simples considèrent alors cela comme du superflu qu'ils veulent retirer.
Et par conséquent, ce qui pour tous ces petits logiciels est probablement juste une question de quelques jours de travail, pour nous, c'est souvent des mois et des mois de travail à équivalent temps plein (on peut d'ailleurs nous aider à atteindre ce temps plein financièrement! On n'y est pas encore). On doit trouver en général des solutions bien plus élégantes que ce que GTK nous propose.
Par exemple, revenons sur nos GtkAction devenus GAction! Il se trouve que puisque le paradigme passe d'un object de GUI (GTK) à un objet plus bas niveau (GLib/GIO), les GAction n'ont pas de concept de "label/titre", ni de "tooltip (info-bulle)", ni de proxy widgets, ni d'icône, etc. Comparez la taille des APIs des liens ci-dessus (c'est à dire notamment le nombre de fonctions; certaines ont été simplement déplacées dans d'autres classes, mais une majorité des concepts d'actions cités ont simplement disparus avec GTK+3!).
J'ai donc réimplémenté notre propre sous-classe GimpAction de GAction ainsi que tous ces différents concepts. En fait, j'ai même implémenté des sous-sous classes pour différents types d'actions. Bien sûr je suis allé plus loin même que ce qu'avait GTK. Par exemple nos nouvelles actions connaissent même leur chemin dans le menu principal:
Recherche d'action montrant le titre, description, le raccourci et le chemin dans le menu
J'ai implémenté pas mal de logiques par signaux pour mettre à jour automatiquement les menus en fonction des actions visibles ou non (encore un concept disparu avec GTK+3 qu'on a dû réimplémenté!), active ou non, l'ajout et retrait dynamique d'actions, etc. On a nos propres modèles de menu (GimpMenuModel), nos propres menus (GimpMenu), nos propres barres de menus (GimpMenuBar), nos propres barres d'outils (GimpToolbar → on peut y voir ma préparation pour de futurs développements — probablement après la sortie de GIMP 3 ceci dit — pour avoir enfin une barre d'outils horizontale dans GIMP!).
Au final, notre nouveau code est encore mieux qu'avant (mais sûrement avec bien plus de bugs, la différence entre un code jeune et un avec 20+ ans de maturité), et avec plus de fonctionnalités, mais la majeure partie de ces nouvelles fonctionnalités ne sont pas dûes au port, mais essentiellement au fait que j'étais au milieu de la réfection totale du code. Alors je pouvais bien en profiter pour rajouter des fonctionnalités qu'on voulait depuis longtemps!
Je n'ai aucun doute que ce sera similaire avec GTK4.
Ensuite est-ce que ce sera plus court que le port GTK+3? Peut-être, j'en sais rien. Ensuite, facile et rapide? Pas d'après mes premières impressions sur la lecture de ce document, ça clairement.
Néanmoins on n'est absolument pas contre. J'ai déjà expliqué à ceux qui nous demandent ce port sur notre tracker: si quelqu'un tient vraiment à cœur de passer rapidement à GTK4 et contribue de son temps pour le faire, ben soyez le bienvenu.
Personnellement je sais que mes objectifs à moyen terme après la sortie de GIMP 3 ne seront pas le port vers GTK4. Lire aussi mon rapport 2022, qui contient une section importante sur les plans futurs de GIMP. Mais je soutiendrai tout contributeur qui veut travailler à porter GIMP vers GTK4. Ça se trouve, GIMP passera vraiment à GTK4 un ou 2 ans après GTK+3. Il suffit d'un seul contributeur qui décide d'y mettre du sien pour que ce soit possible (tout est possible! Qui sait, si on tombe sur un super contributeur super doué et qui s'y met à fond, le portage pourrait même se compter en mois!).
Mais dire que c'est facile, en tous cas, j'en doute très fortement. Ou alors faites le pour me prouver que j'ai tort (j'en serai le premier ravi!). 😜
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Bientôt GTK 4
Posté par Jehan (site web personnel, Mastodon) . En réponse au lien The GTK+3 port of GIMP is officially finished - @zemarmot. Évalué à 10. Dernière modification le 20 avril 2023 à 15:06.
C'est effectivement ce qu'aiment bien répéter les gens qui n'iront pas faire le portage eux-même, ou qui ont juste porté des logiciels simplistes avec 3 fenêtres (ce n'est pas un reproche, il y a de la place pour les logiciels simples, et c'est d'ailleurs la majorité des logiciels GNOME; néanmoins GIMP n'est pas de cette catégorie).
Perso je ne sais pas encore, puisque je n'ai pas même essayé. Néanmoins j'ai déjà jeté un œil (rapide) sur le document de migration GTK+3 vers GTK4. On notera déjà la longueur du document. C'est pas juste une page A4! Mais bon passons la frayeur initiale, et regardons un peu en détail.
Puisque je viens de passer du temps sur le port des actions de l'ancien paradigme (GTK+2) au "nouveau" (GTK+3), voyons donc si quelque chose change encore. Je découvre donc que GtkMenu, GtkMenuBar et GtkMenuItem sont retirés 😱. Pour avoir passé plus de 2 mois à être passé des anciennes
GtkActionetGtkUIManageret compagnie versGAction,GMenuModel,GtkMenu,GtkMenuItem, etc. (c'est le sujet de mon tweet/toot que tout le monde recopie ces derniers jours!), découvrir que la moitié des API utilisées par mon travail de port a déjà été retirée, ça me met pas en joie!En gros, dans GTK, entre la version 2 et 3, on nous fait passer d'une logique à une nouvelle. Et la nouvelle logique est elle-même à moitié supprimée dès le passage à la version 4. Alors heureusement la moitié du travail est encore valide (
GAction,GMenuModel, etc.) mais bon... j'aurais bien aimé que ce soit l'entièreté et qu'on change pas de paradigme tous les 4 matins!Et encore, je dis que j'ai passé plus de 2 mois, mais mon co-mainteneur avait déjà commencé en partie ce travail y a quelques années; et même maintenant c'est pas "totalement" fini (on a tellement d'usages avancés des actions que je trouve encore constamment des bugs à corriger et des fonctionnalités à réimplémenter pour éviter les régressions avec ce nouveau code), même si on va considérer que ça l'est d'un point de vue "le cœur du travail est fait".
Notons qu'en fait, on peut déjà faire pas mal de trucs sans
GtkMenu*même dans GTK+3, car GTK est capable de générer des menus de lui-même à partir d'un modèle (dans certains cas), mais la raison pour laquelle on continue d'écrire nos propres menus (en plus du fait qu'il y avait des parties de GIMP où on n'avait pas le choix de toutes façons) est que GTK a choisi de simplifier son usage des menus. Par exemple les menus créés par l'API de base ne peuvent plus avoir de tooltips (info-bulles), ce qui est malheureusement connu et la proposition d'ajout fut refusée.Pour un logiciel complexe comme GIMP avec des dizaines de filtres et d'actions complexe, la possibilité d'avoir des info-bulles détaillant un peu plus ce que fait une action ou un filtre au nom scientifique/technique parfois un peu barbare me paraît comme une fonctionnalité importante que je voulais pas perdre dans nos menus.
De manière générale, nos menus sont assez avancés, avec des info-bulles, parfois des couleurs, des labels changeants, des petites icônes et des prévisualisations d'image, etc.
Enfin bon, le premier truc, c'est donc que j'ai quand même un peu l'impression d'avoir à réimplémenter dans GIMP des trucs (qui existaient avant) parce que le toolkit juge cela non nécessaire désormais et a retiré la fonctionnalité. D'ailleurs ce sont aussi des remarques que je peux faire avec Wayland et les "portails" où on fait des aller-retours entre les recommandations de tout faire en portail dorénavant et la constatation que l'on y perd des fonctionnalités, dont notamment la gestion d'espaces de couleurs, ce qui est problématique pour un logiciel d'imagerie!
C'est d'ailleurs un constat que m'ont fait explicitement plusieurs des développeurs principaux de GTK. Ce dernier se focalise désormais sur les applications simples. À nous de réimplémenter les usages d'UI complexes.
Bon c'est juste un point. Mais de manière générale, quand je lis cette page en diagonale, à peu près tous les points de cette liste nous touchent:
Ce n'est pas un remplacement en search-and-replace dont il est question ici puisque maintenant il faudra remplacer chaque cas par une fonction spécifique en fonction de la sous-classe réelle. C'est donc plus de 900 cas à gérer en cas par cas.
Encore une fois, le document indique que le remplacement doit se faire au cas par cas (on ne peut pas juste faire un remplacement massif).
GtkListViewetGtkColumnView. Bon le bon point là (contrairement aux points précédents), c'est que c'est pas encore retiré, seulement déprécié depuis GTK 4.10 (on pourrait donc décider de ne pas changer ça immédiatement, mais alors on va encore se farcir des centaines de warnings à la compilation). AlorsGtkTreeView, c'est une API absolument horrible, y a pas à dire. Très complète et puissante, mais vraiment dure à utiliser conceptuellement. J'ai un peu une relation amour-haine avec. Néanmoins les faits est qu'on utilise cela massivement dans GIMP. Rien qu'à l'idée de réimplementer nos dockables d'items, par exemple la liste des calques, me donne mal à la tête. Notre GUI de liste de calque est l'une des plus avancées et complètes que vous pourriez imaginer au niveau fonctionnalités. On peut un peu tout faire avec du glisser-déposer, y a des fonctions spéciales un peu partout avec des clics gauche, droit, milieu, avec des modificateurs, etc. Ça a vraiment été rendu super puissant pour les besoins et l'efficacité des utilisateurs avancés.Enfin bon, un énorme chantier en perspective, celui-là.
En fait je suis pas sûr s'il y a même un seul point de cette liste qui ne nous concerne pas (j'en ai juste cité quelques uns évidents au hasard, mais ensuite il convient de voir chaque point en détail).
GIMP utilise quasiment tous les anciens widgets et probablement tous les usages avancés de ces widgets (dont beaucoup ont été conçus pour et peut-être par les développeurs de GIMP à travers les âges). Le problème, c'est qu'on est peut-être aussi les seuls à les utiliser, et probablement, cela pose problème car ceux qui travaillent sur des interfaces plus simples considèrent alors cela comme du superflu qu'ils veulent retirer.
Et par conséquent, ce qui pour tous ces petits logiciels est probablement juste une question de quelques jours de travail, pour nous, c'est souvent des mois et des mois de travail à équivalent temps plein (on peut d'ailleurs nous aider à atteindre ce temps plein financièrement! On n'y est pas encore). On doit trouver en général des solutions bien plus élégantes que ce que GTK nous propose.
Par exemple, revenons sur nos
GtkActiondevenusGAction! Il se trouve que puisque le paradigme passe d'un object de GUI (GTK) à un objet plus bas niveau (GLib/GIO), lesGActionn'ont pas de concept de "label/titre", ni de "tooltip (info-bulle)", ni de proxy widgets, ni d'icône, etc. Comparez la taille des APIs des liens ci-dessus (c'est à dire notamment le nombre de fonctions; certaines ont été simplement déplacées dans d'autres classes, mais une majorité des concepts d'actions cités ont simplement disparus avec GTK+3!).J'ai donc réimplémenté notre propre sous-classe
GimpActiondeGActionainsi que tous ces différents concepts. En fait, j'ai même implémenté des sous-sous classes pour différents types d'actions. Bien sûr je suis allé plus loin même que ce qu'avait GTK. Par exemple nos nouvelles actions connaissent même leur chemin dans le menu principal:Recherche d'action montrant le titre, description, le raccourci et le chemin dans le menu
J'ai implémenté pas mal de logiques par signaux pour mettre à jour automatiquement les menus en fonction des actions visibles ou non (encore un concept disparu avec GTK+3 qu'on a dû réimplémenté!), active ou non, l'ajout et retrait dynamique d'actions, etc. On a nos propres modèles de menu (
GimpMenuModel), nos propres menus (GimpMenu), nos propres barres de menus (GimpMenuBar), nos propres barres d'outils (GimpToolbar→ on peut y voir ma préparation pour de futurs développements — probablement après la sortie de GIMP 3 ceci dit — pour avoir enfin une barre d'outils horizontale dans GIMP!).Au final, notre nouveau code est encore mieux qu'avant (mais sûrement avec bien plus de bugs, la différence entre un code jeune et un avec 20+ ans de maturité), et avec plus de fonctionnalités, mais la majeure partie de ces nouvelles fonctionnalités ne sont pas dûes au port, mais essentiellement au fait que j'étais au milieu de la réfection totale du code. Alors je pouvais bien en profiter pour rajouter des fonctionnalités qu'on voulait depuis longtemps!
Je n'ai aucun doute que ce sera similaire avec GTK4.
Ensuite est-ce que ce sera plus court que le port GTK+3? Peut-être, j'en sais rien. Ensuite, facile et rapide? Pas d'après mes premières impressions sur la lecture de ce document, ça clairement.
Néanmoins on n'est absolument pas contre. J'ai déjà expliqué à ceux qui nous demandent ce port sur notre tracker: si quelqu'un tient vraiment à cœur de passer rapidement à GTK4 et contribue de son temps pour le faire, ben soyez le bienvenu.
Personnellement je sais que mes objectifs à moyen terme après la sortie de GIMP 3 ne seront pas le port vers GTK4. Lire aussi mon rapport 2022, qui contient une section importante sur les plans futurs de GIMP. Mais je soutiendrai tout contributeur qui veut travailler à porter GIMP vers GTK4. Ça se trouve, GIMP passera vraiment à GTK4 un ou 2 ans après GTK+3. Il suffit d'un seul contributeur qui décide d'y mettre du sien pour que ce soit possible (tout est possible! Qui sait, si on tombe sur un super contributeur super doué et qui s'y met à fond, le portage pourrait même se compter en mois!).
Mais dire que c'est facile, en tous cas, j'en doute très fortement. Ou alors faites le pour me prouver que j'ai tort (j'en serai le premier ravi!). 😜
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]