J'ai moinssé ton commentaire et m'en explique : as-tu une idée du boulot qu'a représenté pour un très petit nombre de personnes et pendant plusieurs années le port vers GTK3 ? Crois-tu que les développeurs concernés puissent se sentir encouragés par ton commentaire ? Crois-tu que ton commentaire n'aie pas d'impact sur des gens ?
Posté par Renault (site web personnel) .
Évalué à 4.
Dernière modification le 20 avril 2023 à 07:54.
Notons que si je ne me trompe pas, les versions majeurs de GTK après GTK3 introduisent moins de changements profonds, le portage devrait être plus facile une fois le port GTK3 effectué. Du moins c'est l'impression que j'en ai.
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:
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 ]
Disons alors s:/matins/ans en moyenne
Mais surtout, ce sont de grosses casses qui peuvent tuer des projets (tous n'ont pas les moyens des GAFAMO et puis devoir rebooter le code chaque fois c'est usant à la longue)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
8/9 ans c'est pas choquant. Le problème c'est qu'on a une masse de code énorme et vieux, maintenu par très peu de personnes. Faut-il que Gtk arrête ou évolue moins vite ? Pas sûr que ça changerait quelque chose d'ailleurs.
Par contre, je n'ai pas la réponse à la question ; je pense juste que ce ne serait pas souhaitable de juste arrêter (ralentir oui, et il semble que c'est déjà le cas si on est maintenant à neuf ans…) ce qui ressort surtout, c'est le manque de bras face à la base de code énorme et sans outils d'assistance…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
De ce que j'ai retenu en tant que béotien, c'est que le passage de GTK+2 à GTK3 impliquait pas mal de changements dû au fait de s'abstraire de X11, d'où de profondes réécritures (plus le projet Ridley d'intégration dans GTK+ de bibliothèques éparses pour sécuriser le truc*)
J'ai cru lire qu'à l'inverse il y avait des outils de conversion GTK3->GTK4 : ai-je halluciné ?
si quelqu'un tient vraiment à cœur de passer rapidement à GTK4
Je constate que 2 ans et 4 mois après la sortie de GTK4, les logiciels qui en dépendent ne sont pas si nombreux, principalement Gnome et Libreoffice. Personnellement, j'ai du mal à évaluer les bénéfices de cette nouvelle version de GTK.
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.
Et sais-tu ce qu'en pensent les développeurs des autres applications complexes avancées basées sur GTK, par exemple Inkscape, LibreOffice, Ardour, voire Firefox ou Thunderbird…
J'ai du mal à comprendre que GTK ait choisi de ne plus leur faciliter le travail.
Non, je ne sais pas ce que pensent les autres. Et je crois que ce n'est pas la bonne question.
Je sais que mon commentaire précédent peut donner l'impression qu'on se plaint du développement de GTK, mais c'est pas du tout là où je voulais en venir. J'expliquais juste en quoi un tel port est complexe et long (contrairement à ce que certains avancent).
Oui, je pense que les dévs GTK auraient pu mieux gérer le passage, mais c'est toujours plus simple à dire qu'à faire. Au final on utilise et on a quand même besoin que GTK évolue (et ce même si on préférerait que la bibliothèque évolue plus souplement, sans tout casser à chaque fois, c'est sûr) et même si on n'est pas d'accord sur tout, ça ne veut pas dire qu'on veut forker GTK par exemple. On est déjà trop peu de développeurs pour GIMP/GEGL/babl pour en plus s'ajouter une autre dépendance majeure. 😅
On prend les passages à de nouvelles versions du toolkit comme une nécessité qu'il faut simplement faire. Un peu comme les corvées de ménage. C'est typiquement la définition de la "dette technologique" en fait. C'est du travail qui n'apporte pas grand chose si ce n'est s'assurer qu'on reste dans la course en suivant le mouvement plus général des changements dans les standards informatiques, les systèmes d'exploitation, etc.
C'est pareil pour nous, et j'imagine pour les autres gros logiciels que tu cites (même si je veux pas trop m'avancer non plus; comme j'ai dit, je sais pas ce que pense autrui!). On fait ces ports parce qu'il faut bien les faire et parce qu'on peut pas rester à jamais sur un toolkit non maintenu et qui ne gère pas (bien ou du tout) le matériel ou logiciels modernes (par exemple: les écrans haute-densité, les tablettes graphiques dont les pilotes utilisent l'API Windows Ink et plus seulement Wintab sur Windows, Wayland pour GNU/Linux…). On se pose pas trop de questions sur si oui ou non GTK aurait pu mieux prendre le virage pour prendre en charge ces nouveaux matériels, logiciels ou usages sans forcer à des mois de travail pour porter, ou sur comment ou pourquoi. On grommelle 💢 certes, mais on fait. Et c'est tout. Je laisse à d'autres le soin de faire des blogs posts pour faire des théories et expliquer pourquoi autrui ne fait pas bien (ce qu'on ne fait pas soi-même), en claquant bruyamment la porte (et en allant par exemple chez Qt, même si ceux-ci ne font pas forcément mieux de ce que je comprends). Il y en a certes qui adorent faire ce genre de choses. 🙄
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
(full disclosure : je ne suis pas du tout programmeur, et je dis donc peut-être de grosses conneries)
Merci d'avoir fait l'effort de rappeler les avantages du changement de version.
Maintenant, quand je te demandais si tu savais ce qu'en pensaient les autres applications avancées, la question que je me posais c'est surtout ne vont-ils pas rencontrer les mêmes problèmes que vous : n'y aurait-il pas des besoins identiques qui donc pourraient être mutualisés, éventuellement sous la forme d'une librairie additionnelle à GTK : pas forcément un fork, mais un truc à la libadwaita, si j'ai bien compris ce que c'était.
Le temps que vous perdriez dans la mise en commun serait gagné par la suite dans le portage.
Je ne suis pas du tout la vie des versions de GTK. Mais la semaine dernière je me suis retrouvé à débugguer un truc dans un projet, ce qui m'a amené à débugguer un truc dans GTK4.
J'ai alors pris note qu'on était à la version 4.
Du coup, quand j'ai vu la news, je me suis demandé si c'était une erreur. Du coup j'ai checké dans GIMP.
Je me suis cru bon (mais j'ai eu tord) de notifier à ceux qui comme moi, n'ont aucune idée des versions de GTK, que ce portage arrive alors qu'il existe déjà la version 4.
# Bientôt GTK 4
Posté par alkino . Évalué à -4.
GTK 4 est sorti en décembre 2020 !
Plus qu'à attendre le port.
[^] # Re: Bientôt GTK 4
Posté par antistress (site web personnel) . Évalué à 10. Dernière modification le 20 avril 2023 à 00:37.
J'ai moinssé ton commentaire et m'en explique : as-tu une idée du boulot qu'a représenté pour un très petit nombre de personnes et pendant plusieurs années le port vers GTK3 ? Crois-tu que les développeurs concernés puissent se sentir encouragés par ton commentaire ? Crois-tu que ton commentaire n'aie pas d'impact sur des gens ?
[^] # Re: Bientôt GTK 4
Posté par Renault (site web personnel) . Évalué à 4. Dernière modification le 20 avril 2023 à 07:54.
Notons que si je ne me trompe pas, les versions majeurs de GTK après GTK3 introduisent moins de changements profonds, le portage devrait être plus facile une fois le port GTK3 effectué. Du moins c'est l'impression que j'en ai.
[^] # Re: Bientôt GTK 4
Posté par antistress (site web personnel) . Évalué à 3.
C'est ce que des commentaires ici avancent
https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1383582-gtk3-port-of-gimp-is-officially-finished
[^] # Re: Bientôt GTK 4
Posté par Jehan (site web personnel, Mastodon) . É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: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 Psychofox (Mastodon) . Évalué à 5. Dernière modification le 20 avril 2023 à 19:09.
GTK1.0: 1998-04-13
GTK2.0: 2002-03-11 3ans 11mois après
GTK3.0: 2011-02-10 8ans 11mois après
GTK4.0: 2020-12-16 9ans 10mois après
Il semble que c'est un peu plus que tous les 4 matins et que la tendance est à se rallonger.
Sinon faut passer à electron.
[^] # Re: Bientôt GTK 4
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
Disons alors
s:/matins/ans en moyenneMais surtout, ce sont de grosses casses qui peuvent tuer des projets (tous n'ont pas les moyens des GAFAMO et puis devoir rebooter le code chaque fois c'est usant à la longue)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Bientôt GTK 4
Posté par ff9097 . Évalué à 2.
8/9 ans c'est pas choquant. Le problème c'est qu'on a une masse de code énorme et vieux, maintenu par très peu de personnes. Faut-il que Gtk arrête ou évolue moins vite ? Pas sûr que ça changerait quelque chose d'ailleurs.
[^] # Re: Bientôt GTK 4
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Par contre, je n'ai pas la réponse à la question ; je pense juste que ce ne serait pas souhaitable de juste arrêter (ralentir oui, et il semble que c'est déjà le cas si on est maintenant à neuf ans…) ce qui ressort surtout, c'est le manque de bras face à la base de code énorme et sans outils d'assistance…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Bientôt GTK 4
Posté par mahikeulbody . Évalué à 5.
C'est aussi problématique entre chaque version de Qt ?
[^] # Re: Bientôt GTK 4
Posté par antistress (site web personnel) . Évalué à 3.
Merci Jehan pour ce point détaillé.
De ce que j'ai retenu en tant que béotien, c'est que le passage de GTK+2 à GTK3 impliquait pas mal de changements dû au fait de s'abstraire de X11, d'où de profondes réécritures (plus le projet Ridley d'intégration dans GTK+ de bibliothèques éparses pour sécuriser le truc*)
J'ai cru lire qu'à l'inverse il y avait des outils de conversion GTK3->GTK4 : ai-je halluciné ?
*cf https://mail.gnome.org/archives/desktop-devel-list/2005-August/msg00140.html & https://wiki.gnome.org/Attic/ProjectRidley
et par ex https://help.gnome.org/misc/release-notes/2.16/index.html.fr#rnbackend-gtk
[^] # Re: Bientôt GTK 4
Posté par Maderios . Évalué à 2.
Je constate que 2 ans et 4 mois après la sortie de GTK4, les logiciels qui en dépendent ne sont pas si nombreux, principalement Gnome et Libreoffice. Personnellement, j'ai du mal à évaluer les bénéfices de cette nouvelle version de GTK.
[^] # Re: Bientôt GTK 4
Posté par hugotrip . Évalué à 3.
Et sais-tu ce qu'en pensent les développeurs des autres applications
complexesavancées basées sur GTK, par exemple Inkscape, LibreOffice, Ardour, voire Firefox ou Thunderbird…J'ai du mal à comprendre que GTK ait choisi de ne plus leur faciliter le travail.
[^] # Re: Bientôt GTK 4
Posté par Jehan (site web personnel, Mastodon) . Évalué à 5.
Non, je ne sais pas ce que pensent les autres. Et je crois que ce n'est pas la bonne question.
Je sais que mon commentaire précédent peut donner l'impression qu'on se plaint du développement de GTK, mais c'est pas du tout là où je voulais en venir. J'expliquais juste en quoi un tel port est complexe et long (contrairement à ce que certains avancent).
Oui, je pense que les dévs GTK auraient pu mieux gérer le passage, mais c'est toujours plus simple à dire qu'à faire. Au final on utilise et on a quand même besoin que GTK évolue (et ce même si on préférerait que la bibliothèque évolue plus souplement, sans tout casser à chaque fois, c'est sûr) et même si on n'est pas d'accord sur tout, ça ne veut pas dire qu'on veut forker GTK par exemple. On est déjà trop peu de développeurs pour GIMP/GEGL/babl pour en plus s'ajouter une autre dépendance majeure. 😅
On prend les passages à de nouvelles versions du toolkit comme une nécessité qu'il faut simplement faire. Un peu comme les corvées de ménage. C'est typiquement la définition de la "dette technologique" en fait. C'est du travail qui n'apporte pas grand chose si ce n'est s'assurer qu'on reste dans la course en suivant le mouvement plus général des changements dans les standards informatiques, les systèmes d'exploitation, etc.
C'est pareil pour nous, et j'imagine pour les autres gros logiciels que tu cites (même si je veux pas trop m'avancer non plus; comme j'ai dit, je sais pas ce que pense autrui!). On fait ces ports parce qu'il faut bien les faire et parce qu'on peut pas rester à jamais sur un toolkit non maintenu et qui ne gère pas (bien ou du tout) le matériel ou logiciels modernes (par exemple: les écrans haute-densité, les tablettes graphiques dont les pilotes utilisent l'API Windows Ink et plus seulement Wintab sur Windows, Wayland pour GNU/Linux…). On se pose pas trop de questions sur si oui ou non GTK aurait pu mieux prendre le virage pour prendre en charge ces nouveaux matériels, logiciels ou usages sans forcer à des mois de travail pour porter, ou sur comment ou pourquoi. On grommelle 💢 certes, mais on fait. Et c'est tout. Je laisse à d'autres le soin de faire des blogs posts pour faire des théories et expliquer pourquoi autrui ne fait pas bien (ce qu'on ne fait pas soi-même), en claquant bruyamment la porte (et en allant par exemple chez Qt, même si ceux-ci ne font pas forcément mieux de ce que je comprends). Il y en a certes qui adorent faire ce genre de choses. 🙄
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 hugotrip . Évalué à 2.
(full disclosure : je ne suis pas du tout programmeur, et je dis donc peut-être de grosses conneries)
Merci d'avoir fait l'effort de rappeler les avantages du changement de version.
Maintenant, quand je te demandais si tu savais ce qu'en pensaient les autres applications avancées, la question que je me posais c'est surtout ne vont-ils pas rencontrer les mêmes problèmes que vous : n'y aurait-il pas des besoins identiques qui donc pourraient être mutualisés, éventuellement sous la forme d'une librairie additionnelle à GTK : pas forcément un fork, mais un truc à la libadwaita, si j'ai bien compris ce que c'était.
Le temps que vous perdriez dans la mise en commun serait gagné par la suite dans le portage.
[^] # Re: Bientôt GTK 4
Posté par alkino . Évalué à 3.
Oups, je m'en excuse.
Je vais expliquer mon message du coup.
Je ne suis pas du tout la vie des versions de GTK. Mais la semaine dernière je me suis retrouvé à débugguer un truc dans un projet, ce qui m'a amené à débugguer un truc dans GTK4.
J'ai alors pris note qu'on était à la version 4.
Du coup, quand j'ai vu la news, je me suis demandé si c'était une erreur. Du coup j'ai checké dans GIMP.
Je me suis cru bon (mais j'ai eu tord) de notifier à ceux qui comme moi, n'ont aucune idée des versions de GTK, que ce portage arrive alors qu'il existe déjà la version 4.
[^] # Re: Bientôt GTK 4
Posté par antistress (site web personnel) . Évalué à 3.
Okay !
[^] # Re: Bientôt GTK 4
Posté par antistress (site web personnel) . Évalué à 3.
Du coup, n'hésites pas à féliciter ou remercier les développeurs ;)
# Bravo !
Posté par rycks . Évalué à 7.
Rien de plus à dire, quel engagement, pugnacité !
Bravo … et merci
eric.linuxfr@sud-ouest.org
# La même info sur un réseau social décentralisé
Posté par pamputt . Évalué à 8. Dernière modification le 20 avril 2023 à 08:59.
C'est ici : https://fosstodon.org/@GIMP@floss.social/110190986668695849
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.