C'est pas une priorité. On fait un logiciel de création graphique, pas une démo technique d'un toolkit graphique. Et passer du temps à changer d'infra juste pour changer d'infra n'est pas la partie marrante (ni ce qu'attendent la plupart des gens qui créent avec GIMP), pour au final passer surtout du temps à réparer les régressions, les nouveaux bugs...
Mais hormis cela, oui bien sûr que c'est prévu à terme. Cela reste une dette technique de rester sur une version qui n'évolue plus.
J'aurais juste bien aimé que les dévs GTK soient un peu plus conservateurs et ne cassent pas fondamentalement leur interface à chaque fois.
Avec du recul, aurait-il été plus judicieux à l'époque de sauter une version et commencer un portage vers GTK 4 ?
Certains sortent cela en effet parfois. Comme si c'était trivial de faire un port d'une version majeure à une autre de GTK. On raconte aussi qu'il serait plus facile à porter de GTK+3 à GTK4 que de GTK+2 à GTK+3.
Alors moi je veux bien, mais on a déjà repéré plusieurs problèmes majeurs, et rien que d'y penser, j'ai mal à la tête. Par exemple, avec GTK4, on perd les menus. Ils ont décidé que les menus à l'ancienne étaient peu utilisés (seulement tous les logiciels majeurs que j'utilise ont des menus! Faut croire que c'était pas assez! 🙄) et trop compliqué. À la place, ils conseillent maintenant d'utiliser des menus popover (le fameux menu hamburger quoi). Puisqu'on n'est pas d'accord, ça veut dire qu'on va devoir réimplementer les barres de menu et tous les autres composants de telles interfaces, les intéractions, etc. Quand je vois déjà le boulot que j'ai fait entre GIMP 2 et GIMP 3 pour changer le code des actions et des menus (avec aussi plein de nouveau code côté GIMP car ça avait déjà commencé à disparaître côté GTK), et notamment que plein de mon nouveau code va déjà partir à la poubelle quand on va passer à GTK4, ça me fait un peu mal.
En fait, plus ça va et plus GTK semble cibler les logiciels simples (les "apps"). Tout ce qui est complexe, type "logiciel métier" ne semble plus trop les intéresser. Ils comprennent pas apparemment qu'un logiciel comme GIMP avec plus de 200 filtres, des dizaines d'outils, fenêtres détachables et ancrables pour des fonctionnalités avancées, et ainsi de suite, a besoin de menus et sous-menus organisés, et pas juste un mini menu hamburger.
Déjà qu'ils ont décidé de retirer les tooltips (info-bulles) sur les éléments de menu dans GTK+3 parce qu'ils considèrent que ce n'est pas une bonne idée. Pour ça aussi, j'ai du faire pas mal de code additionnel pour faire notre propre code de génération de menu. Non parce que c'est sûr que pour des "apps" avec 3 actions au nom explicite, je peux comprendre qu'on trouve les infos bulles inutiles. Mais pour un logiciel métier à la pointe du graphisme, avec beaucoup de filtres qui sortent du monde académique, ben pouvoir expliciter des usages principaux ou des descriptions plus détaillés pour certaines actions n'est pas du luxe. Et c'est pas juste qu'il faudrait trouver un meilleur nom pour l'action. Beaucoup de ces noms sont communs entre tous ces logiciels et ont un nom certes scientifique mais passé dans les normes. Que ce soit un flou gaussien, ou un filtre passe-haut, ou autre... Et même les filtres avec des noms plus "sympas" pour le grand public, une petite description un peu plus longue n'est vraiment pas du luxe.
Le second autre gros point noir qui va demander beaucoup de travail est la disparition de GtkTreeView. Alors on pourrait rétorquer que c'est juste une dépréciation (depuis 4.10) et qu'on pourrait donc juste de contenter de garder ce code pour GIMP 4. Sauf que tout développeur sait que garder du code déprécié jusqu'à la dernière seconde n'est pas idéal (sauf dans certains cas, par exemple si le but est d'avoir du code qui marche à la fois dans de vieilles versions et de nouvelles d'une dépendance; mais ce sera pas le cas ici). Notamment si on ne veut pas être noyé de messages de dépréciation en compilant son code (qui a le mauvais goût de cacher les vrais messages problématiques, qui soulignent des bugs dans le code, noyés sous la masse). Encore une fois, on nous dit que les logiciels modernes n'utilisent pas de vue en arborescence. 🤦♂️ Alors on nous dit que si on veut vraiment simuler une vue en arborescence, on peut utiliser une view en liste et y mettre des "expanders" (les widgets pour cacher du contenu derrière un titre avec le petit triangle à cliquer) à la main, plutôt qu'avoir une structure de vue en arbre faite pour.
Bien sûr, on utilise la vue en arbre partout: que ce soit les calques, mais aussi dans pas mal d'autres endroits du code. Bon pour pas mal de bouts de code, la recommandation d'utiliser une liste avec des "expanders" sera vraisemblablement un hack suffisant. Mais pour les parties où la logique en arborescence est vraiment un élément structurel fondamental (justement les calques par exemple), on devra sûrement faire du nouveau code à nous pour faire ça bien, propre conceptuellement et performant. Et je sais déjà que ce sera pas une balade dans le parc.
Enfin bon, en conclusion: passer d'une version de GTK à une autre n'est pas une partie de plaisir, surtout s'ils s'amusent à retirer des fonctionnalités fondamentales à chaque fois.
Et dans les faits, en écumant les forums, on se rend compte que tous les gens qui utilisent vraiment GIMP de manière approfondie voire professionnelles semblent à peine faire attention aux montées de la version du toolkit. C'est pas vraiment ça qui les intéresse ou qui leur permet de faire du meilleur boulot. Ceux qui font le plus de remarques à ce sujet semblent être ceux qui utilisent GIMP de manière anecdotique (voire pas du tout pour certains, on le voit à ce qu'ils disent sur des trucs qui ne sont plus vrais depuis des années, voire décennies) et qui s'arrêtent au visuel. D'ailleurs c'est un peu comme Wayland. Tous les professionnels que l'on rencontrent (dont nous-même!) persistons à utiliser X11. Parce que malgré toutes les promesses de monts et merveilles de Wayland, il y a encore trop de fonctionnalités de base manquantes dans Wayland, dont la correction colorimétrique qui est encore et toujours en discussion et notamment parce que je me suis bien rendu compte que cela mélange des besoins très différents; notamment ils accordent énormément d'importance aux usages de type "je veux juste des couleurs les plus pêtantes possible parce que j'ai un écran à gamut large" (typiquement: je joue à des jeux vidéos et j'en veux plein la tronche, ou je vends des télés et je veux que les explosions dans ma télé se voient plus que dans celle du concurrent) et non pas "je veux des couleurs correctes" (par exemple si je suis un professionnel du graphisme). Mais il y a aussi encore trop régulièrement des problèmes avec les tablettes graphiques, ou bien des problèmes de stabilité (au point que certains se mettent à échanger des astuces pour lancer GIMP par XWayland; Krita de leur côté ont carrêment hardcodé l'usage de XWayland en disant que Krita ne prend pas en charge Wayland pour l'instant donc les gens ne peuvent même pas lancer le logiciel en pur Wayland).
Enfin bon, nouveau tout de suite n'est pas forcément mieux. Que ce soit pour GTK ou Wayland.
Il est effectivement fait mention d'une volonté de se "concentrer sur des versions plus petites et axées sur les fonctionnalités", ce qui est évidemment une super nouvelle.
En vrai, on fait cela depuis 2018, c'est à dire depuis GIMP 2.10.0. On a sorti 20 versions stables (2.10.0 à 2.10.40), soit à peu près 3 par an, à chaque fois avec de nouvelles fonctionnalités en pagaille. La seule différence, c'est qu'à ce moment, on avait rompu avec notre système de versionnement historique pour accepter de nouvelles fonctionnalités sur des sorties "micro" (qui jusque là étaient seulement pour les corrections de bugs), parce qu'il avait déjà été décidé que 2.10 serait la dernière version mais qu'on voulait pouvoir sortir des changements majeurs plus souvent (par tous les X années).
La différence là est qu'on revient sur ce changement. Les sorties micro (troisième nombre) seront à nouveau des sorties de correction de bug uniquement, et additionnellement à cela, on sortira des versions mineures (second nombre) plus vite, avec les fonctionnalités. C'est donc un mix de comment cela fonctionnait en 2.10 et avant (2.8, 2.6...).
Encore une fois, tous ceux qui utilisent vraiment GIMP au quotidien et ont suivi les évolutions ont bien vu que ce n'est pas la partie la plus innovante, puisque c'est déjà ce qu'on faisait depuis 2018. Si on change, c'est surtout parce que tous ceux qui regardent de loin racontent un peu de fariboles et répandent partout que GIMP a pas évolué depuis la version 2.10. Ensuite y a pire. Y a ceux qui prétendent que GIMP n'a pas changé depuis la version 2.0 (ceux-là se fient au premier chiffre seulement), et le pire, c'est quand c'est repris dans de plus gros médias (oui, j'ai bien vu qu'ils ont mis un petit paragraphe au milieu admettant quelques versions "intermédiaires", mais bon clairement le titre et le reste de l'article est là pour dire "il s'est quasi rien passé depuis 20 ans"; ce serait comique si c'était pas également un peu frustrant, alors qu'on fait des sorties avec de gros changements tous les quelques mois depuis des années déjà 😅).
Dans tous les cas, un énorme bravo à toutes les personnes impliquées dans le projet et la sortie de cette version bien plus que symbolique. GIMP est un véritable étendard du logiciel libre sur environnement de bureau et vous pouvez être fiers du travail accompli jusqu'à présent.
Merci. 💌
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GTK 4
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 3.0 RC1 est sorti. Évalué à 10.
C'est pas une priorité. On fait un logiciel de création graphique, pas une démo technique d'un toolkit graphique. Et passer du temps à changer d'infra juste pour changer d'infra n'est pas la partie marrante (ni ce qu'attendent la plupart des gens qui créent avec GIMP), pour au final passer surtout du temps à réparer les régressions, les nouveaux bugs...
Mais hormis cela, oui bien sûr que c'est prévu à terme. Cela reste une dette technique de rester sur une version qui n'évolue plus.
J'aurais juste bien aimé que les dévs GTK soient un peu plus conservateurs et ne cassent pas fondamentalement leur interface à chaque fois.
Certains sortent cela en effet parfois. Comme si c'était trivial de faire un port d'une version majeure à une autre de GTK. On raconte aussi qu'il serait plus facile à porter de GTK+3 à GTK4 que de GTK+2 à GTK+3.
Alors moi je veux bien, mais on a déjà repéré plusieurs problèmes majeurs, et rien que d'y penser, j'ai mal à la tête. Par exemple, avec GTK4, on perd les menus. Ils ont décidé que les menus à l'ancienne étaient peu utilisés (seulement tous les logiciels majeurs que j'utilise ont des menus! Faut croire que c'était pas assez! 🙄) et trop compliqué. À la place, ils conseillent maintenant d'utiliser des menus popover (le fameux menu hamburger quoi). Puisqu'on n'est pas d'accord, ça veut dire qu'on va devoir réimplementer les barres de menu et tous les autres composants de telles interfaces, les intéractions, etc. Quand je vois déjà le boulot que j'ai fait entre GIMP 2 et GIMP 3 pour changer le code des actions et des menus (avec aussi plein de nouveau code côté GIMP car ça avait déjà commencé à disparaître côté GTK), et notamment que plein de mon nouveau code va déjà partir à la poubelle quand on va passer à GTK4, ça me fait un peu mal.
En fait, plus ça va et plus GTK semble cibler les logiciels simples (les "apps"). Tout ce qui est complexe, type "logiciel métier" ne semble plus trop les intéresser. Ils comprennent pas apparemment qu'un logiciel comme GIMP avec plus de 200 filtres, des dizaines d'outils, fenêtres détachables et ancrables pour des fonctionnalités avancées, et ainsi de suite, a besoin de menus et sous-menus organisés, et pas juste un mini menu hamburger.
Déjà qu'ils ont décidé de retirer les tooltips (info-bulles) sur les éléments de menu dans GTK+3 parce qu'ils considèrent que ce n'est pas une bonne idée. Pour ça aussi, j'ai du faire pas mal de code additionnel pour faire notre propre code de génération de menu. Non parce que c'est sûr que pour des "apps" avec 3 actions au nom explicite, je peux comprendre qu'on trouve les infos bulles inutiles. Mais pour un logiciel métier à la pointe du graphisme, avec beaucoup de filtres qui sortent du monde académique, ben pouvoir expliciter des usages principaux ou des descriptions plus détaillés pour certaines actions n'est pas du luxe. Et c'est pas juste qu'il faudrait trouver un meilleur nom pour l'action. Beaucoup de ces noms sont communs entre tous ces logiciels et ont un nom certes scientifique mais passé dans les normes. Que ce soit un flou gaussien, ou un filtre passe-haut, ou autre... Et même les filtres avec des noms plus "sympas" pour le grand public, une petite description un peu plus longue n'est vraiment pas du luxe.
Le second autre gros point noir qui va demander beaucoup de travail est la disparition de GtkTreeView. Alors on pourrait rétorquer que c'est juste une dépréciation (depuis 4.10) et qu'on pourrait donc juste de contenter de garder ce code pour GIMP 4. Sauf que tout développeur sait que garder du code déprécié jusqu'à la dernière seconde n'est pas idéal (sauf dans certains cas, par exemple si le but est d'avoir du code qui marche à la fois dans de vieilles versions et de nouvelles d'une dépendance; mais ce sera pas le cas ici). Notamment si on ne veut pas être noyé de messages de dépréciation en compilant son code (qui a le mauvais goût de cacher les vrais messages problématiques, qui soulignent des bugs dans le code, noyés sous la masse). Encore une fois, on nous dit que les logiciels modernes n'utilisent pas de vue en arborescence. 🤦♂️ Alors on nous dit que si on veut vraiment simuler une vue en arborescence, on peut utiliser une view en liste et y mettre des "expanders" (les widgets pour cacher du contenu derrière un titre avec le petit triangle à cliquer) à la main, plutôt qu'avoir une structure de vue en arbre faite pour.
Bien sûr, on utilise la vue en arbre partout: que ce soit les calques, mais aussi dans pas mal d'autres endroits du code. Bon pour pas mal de bouts de code, la recommandation d'utiliser une liste avec des "expanders" sera vraisemblablement un hack suffisant. Mais pour les parties où la logique en arborescence est vraiment un élément structurel fondamental (justement les calques par exemple), on devra sûrement faire du nouveau code à nous pour faire ça bien, propre conceptuellement et performant. Et je sais déjà que ce sera pas une balade dans le parc.
Enfin bon, en conclusion: passer d'une version de GTK à une autre n'est pas une partie de plaisir, surtout s'ils s'amusent à retirer des fonctionnalités fondamentales à chaque fois.
Et dans les faits, en écumant les forums, on se rend compte que tous les gens qui utilisent vraiment GIMP de manière approfondie voire professionnelles semblent à peine faire attention aux montées de la version du toolkit. C'est pas vraiment ça qui les intéresse ou qui leur permet de faire du meilleur boulot. Ceux qui font le plus de remarques à ce sujet semblent être ceux qui utilisent GIMP de manière anecdotique (voire pas du tout pour certains, on le voit à ce qu'ils disent sur des trucs qui ne sont plus vrais depuis des années, voire décennies) et qui s'arrêtent au visuel. D'ailleurs c'est un peu comme Wayland. Tous les professionnels que l'on rencontrent (dont nous-même!) persistons à utiliser X11. Parce que malgré toutes les promesses de monts et merveilles de Wayland, il y a encore trop de fonctionnalités de base manquantes dans Wayland, dont la correction colorimétrique qui est encore et toujours en discussion et notamment parce que je me suis bien rendu compte que cela mélange des besoins très différents; notamment ils accordent énormément d'importance aux usages de type "je veux juste des couleurs les plus pêtantes possible parce que j'ai un écran à gamut large" (typiquement: je joue à des jeux vidéos et j'en veux plein la tronche, ou je vends des télés et je veux que les explosions dans ma télé se voient plus que dans celle du concurrent) et non pas "je veux des couleurs correctes" (par exemple si je suis un professionnel du graphisme). Mais il y a aussi encore trop régulièrement des problèmes avec les tablettes graphiques, ou bien des problèmes de stabilité (au point que certains se mettent à échanger des astuces pour lancer GIMP par XWayland; Krita de leur côté ont carrêment hardcodé l'usage de XWayland en disant que Krita ne prend pas en charge Wayland pour l'instant donc les gens ne peuvent même pas lancer le logiciel en pur Wayland).
Enfin bon, nouveau tout de suite n'est pas forcément mieux. Que ce soit pour GTK ou Wayland.
En vrai, on fait cela depuis 2018, c'est à dire depuis GIMP 2.10.0. On a sorti 20 versions stables (2.10.0 à 2.10.40), soit à peu près 3 par an, à chaque fois avec de nouvelles fonctionnalités en pagaille. La seule différence, c'est qu'à ce moment, on avait rompu avec notre système de versionnement historique pour accepter de nouvelles fonctionnalités sur des sorties "micro" (qui jusque là étaient seulement pour les corrections de bugs), parce qu'il avait déjà été décidé que 2.10 serait la dernière version mais qu'on voulait pouvoir sortir des changements majeurs plus souvent (par tous les X années).
La différence là est qu'on revient sur ce changement. Les sorties micro (troisième nombre) seront à nouveau des sorties de correction de bug uniquement, et additionnellement à cela, on sortira des versions mineures (second nombre) plus vite, avec les fonctionnalités. C'est donc un mix de comment cela fonctionnait en 2.10 et avant (2.8, 2.6...).
Encore une fois, tous ceux qui utilisent vraiment GIMP au quotidien et ont suivi les évolutions ont bien vu que ce n'est pas la partie la plus innovante, puisque c'est déjà ce qu'on faisait depuis 2018. Si on change, c'est surtout parce que tous ceux qui regardent de loin racontent un peu de fariboles et répandent partout que GIMP a pas évolué depuis la version 2.10. Ensuite y a pire. Y a ceux qui prétendent que GIMP n'a pas changé depuis la version 2.0 (ceux-là se fient au premier chiffre seulement), et le pire, c'est quand c'est repris dans de plus gros médias (oui, j'ai bien vu qu'ils ont mis un petit paragraphe au milieu admettant quelques versions "intermédiaires", mais bon clairement le titre et le reste de l'article est là pour dire "il s'est quasi rien passé depuis 20 ans"; ce serait comique si c'était pas également un peu frustrant, alors qu'on fait des sorties avec de gros changements tous les quelques mois depuis des années déjà 😅).
Merci. 💌
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]