Moins d’un mois après la sortie de GIMP 2.10.0, nous sortons une première version mineure.
Suite au changement de politique de sortie, cette version mineure ne se contente pas de corriger de nombreux bogues, elle apporte aussi de nouvelles fonctionnalités ! C’est la raison pour laquelle je me permets une nouvelle dépêche plutôt qu’un simple journal.
Sommaire
- Corrections de bogues et activité de développement
- Nouvelles fonctionnalités
- Quelques améliorations notables
- Coopérer avec les tiers
- Autres évolutions
Corrections de bogues et activité de développement
Entre GIMP 2.10.0 et 2.10.2, en moins d’un mois, 292 commits se sont produits (soit une moyenne de 12 commits par jour, dont plus de 60 % par trois développeurs) et 44 bogues corrigés.
Il s’agit donc d’un développement très actif, bien que limité par le faible nombre de développeurs.
Nouvelles fonctionnalités
Prise en charge du format HEIF
GIMP 2.10.2 propose la prise en charge du format d’image HEIF, en lecture et écriture, contribué par Dirk Farin.
De nouveaux filtres
Deux nouveaux filtres ont aussi été ajoutés :
- le filtre Spherize qui crée comme une sorte de « bulle » sur laquelle l’image se colle :
Filtre Spherize sur une image CC By-SA par Aryeom Han (projet ZeMarmot)
- le filtre Recursive Transform, notamment utilisable pour créer des effets Droste :
Filtre Recursive Transform sur une image CC By-SA par Philipp Haegi
Filtre Spherize sur une image CC By-SA par 
Filtre Recursive Transform sur une Quelques améliorations notables
Amélioration de performances (calcul d’histogrammes)
Les histogrammes sont désormais calculés dans des fils d’exécution séparés, libérant ainsi le fil d’exécution principal et améliorant encore plus la réactivité de l’interface graphique. Cela fait suite aux diverses améliorations des performances de GIMP depuis la version 2.10.0.
Greffon de capture d’écran amélioré pour Windows
Sur les systèmes Microsoft, la capture d’écran par fenêtre ne fonctionnait pas si la fenêtre était cachée ou hors du champ du bureau. Cela est désormais réparé.
Coopérer avec les tiers
GIMP est un logiciel très répandu et, par conséquent, nous avons beaucoup d’interaction avec des projets tiers. Trouver une logique de coopération est donc important.
Rapports de bogues et paquets tiers
L’une des problématiques est de permettre aux empaqueteurs de gérer leurs utilisateurs. En effet, GIMP est rapidement empaqueté par de nombreuses personnes et entités. Parfois certains font même des binaires plus rapidement que le projet GIMP (notamment pour Windows et macOS).
Malheureusement, cela signifie que nous recevons aussi beaucoup de rapports de bogues pour des problèmes spécifiques à des paquets tiers, par exemple lorsqu’ils ont modifié le code source, ou bien ont rajouté des greffons tiers ou au contraire retiré des fonctionnalités, ont des problèmes de dépendances, de compilation, etc.
Recevoir des dizaines de rapports de bogues pour ces divers paquets (par exemple, pour une version PortableApp, un paquet Arch Linux, etc.) et devoir les gérer, faire du débogage, pour finalement comprendre que le problème est dans le paquet et demander à tous les utilisateurs de rapporter le problème à l’empaqueteur, gérer les duplicatas, etc., nous prend énormément de temps que l’on préférerait passer à améliorer GIMP.
Dans tous les cas, il est souvent préférable de rapporter les bogues auprès de l’empaqueteur, qui peut effectuer un premier tri avant éventuellement de nous rapporter le bogue (une seule fois) s’il estime qu’il se trouve dans le code source, après avoir testé.
C’est pourquoi j’ai rajouté l’option de compilation --with-bug-report-url permettant à un empaqueteur de préciser sa propre adresse d’outil de suivi, qui sera ouverte notamment en cas de plantage de GIMP.
Lecture de XCF par programmes tiers
Le format XCF n’est pas un format d’échange (contrairement par exemple au format OpenRaster). Son but est d’être le plus proche possible du fonctionnement interne de GIMP, en suivant les fonctionnalités.
Néanmoins il est normal que d’autres logiciels souhaitent tout de même pouvoir lire ces fichiers. Dès 2006, un contributeur (Henning Makholm) avait documenté le format XCF et cette documentation avait finalement été intégrée dans notre dépôt de source. Nous avons reçu quelques demandes répétées de mettre à jour cette documentation. J’ai donc pris une journée et demi pour la mettre à jour avec les changements du format depuis GIMP 2.8 (si des imprécisions ou des erreurs subsistent, chacun est le bienvenu pour déposer un rapport de bogue).
Les nombreux logiciels souhaitant prendre en charge XCF sont donc invités à se mettre à jour. Notez que la version git log peut être plus intéressante pour distinguer plus aisément le différentiel entre GIMP 2.8 et GIMP 2.10.
Autres évolutions
Flatpak
Nous rappelons que GIMP est désormais disponible en version Flatpak officielle (maintenue par l’équipe de GIMP, en particulier par moi‐même). Encore une fois, cette version binaire est même sortie la première, avant un installeur Windows ou un paquet macOS !
Néanmoins, nous avons aussi eu plusieurs remarques concernant cette version et ses limitations (dues en partie au modèle de sandbox, la jeunesse de la technologie Flatpak et la non‐adaptation de GIMP à certains aspects du modèle).
Je souhaite donc rappeler que (contrairement aux plates‐formes Windows et macOS), le paquet de votre distribution GNU/Linux est encore la méthode officiellement recommandée par le projet GIMP ! Cela était déjà clairement noté sur notre page de téléchargement, mais pas assez mis en avant. J’ai donc un peu remis en page le texte sur gimp.org/download pour que cela soit plus clair :
Bien sûr, cela pourra changer, mais pour l’instant certaines fonctionnalités sont perdues, comme l’utilisation de darktable et RawTherapeee comme greffons pour ouvrir les fichier RAW (ces logiciels étant recherchés par le $PATH, et n’étant pas accessibles dans un environnement bac à sable), ou encore le contrôle de GIMP par des périphériques MIDI, etc.
Les avantages de Flatpak à ce jour sont : la mise à jour au plus tôt après une sortie de GIMP (alors que les distributions peuvent avoir plusieurs mois de retard, voire années pour des LTS), un système auto‐contenu pouvant être lancé depuis n’importe quelle distribution, et une version disponible et utilisable directement pour quatre architectures, notamment ARM et AArch64 (donc, a priori, installer GIMP sur un Raspberry Pi devrait être possible en un clic ou une commande, mais je n’ai jamais testé !).
Source et suivi de bogues migrés sur le GitLab de GNOME
Une autre évolution majeure dans notre processus de travail est que nous suivons GNOME dans leur migration vers le logiciel Gitlab.
Cela fait suite à un projet de migration de longue haleine, de la part de nos amis de chez GNOME, et qui touche à sa fin.
Le déménagement de GIMP est effectif depuis jeudi 24 mai 2018 (le source est déjà présent et les rapports de bogues en cours de migration à l’heure d’écriture de ces lignes). Vous pouvez désormais obtenir le code source de GIMP et créer de nouveaux rapports de bogues à cette adresse : https://gitlab.gnome.org/GNOME/gimp.
Nous noterons que GNOME effectue cette migration en collaboration avec l’entreprise GitLab (de ce que j’en ai compris), qui effectue des modifications dans son logiciel pour les besoins des projets GNOME et amis.
Notamment, il est à noter que nous refusons les « commits de fusion » chez GIMP (même si parfois, certains apparaissent subrepticement), pour raison de lisibilité de l’historique, ce qui est un gros problème avec le processus de « demande d’intégration / demande de fusion » (Pull Request / Merge Request) propre à ce type de plate‐forme, et était donc un des freins de nombreux projets. Cela fait donc partie des changements fait par GitLab pour accueillir certains projets qui ont la possibilité de désactiver de tels commits non désirés (ce que GIMP a donc fait).
Notons que tout est encore un peu flou, et que je ne suis pas certain de beaucoup de détails, ce qui est normal, car le changement est frais de quelques heures ! Nous verrons donc dans les jours qui suivent.
En tout cas, je sais que c’est un appel d’air frais que beaucoup trouveront bienvenu, car certains semblaient redouter le vieillissant Bugzilla. Je souhaiterais cependant prendre un peu le contrepied de cette opinion populaire en remerciant les nombreux développeurs de Bugzilla, qui nous ont fourni un excellent logiciel pendant de nombreuses années — certes, avec ses imperfections, mais quel logiciel n’en a pas ? Surtout un logiciel né en 1998, soit à peine moins vieux que GIMP !
Merci Bugzilla ! Tu as fait du super boulot et on te souhaite de continuer à aider plein d’autres projets pendant longtemps !
GIMP 3 : le voyage a commencé
Nous avons commencé à travailler sur GIMP 3, qui est le portage de GIMP en GTK+ 3, et c’est extrêmement excitant ! En fait, le jour de la sortie de GIMP 2.10.0, le travail sur GIMP 3 a commencé de manière poussée (plus de 200 commits en un mois, en plus donc des commits sur la branche stable, dont les statistiques sont notées plus haut). L’une des tâches principales du portage étant de nettoyer le source de bouts de code ou de données obsolètes rendus inutiles par GTK+ 3. En un mois, cette branche a ainsi connu 9 805 lignes de codes insérées pour 921 630 lignes supprimées (NdM.: 50k de code et ~870k de SVG) !
Certains des développeurs principaux de GIMP représentés par Aryeom
Notons aussi que le jour de la sortie de GIMP 2.10.2, le portage vers GTK+ 3 est devenu officiellement notre branche principale (master), le signe qu’il s’agit maintenant de notre nouvelle priorité numéro 1.
N. D. M. : Jehan est non seulement un fidèle écrivain sur LinuxFr.org, l’un des principaux développeurs de GIMP, mais aussi et surtout l’auteur avec Aryeom du film d’animation ZeMarmot dont on a beaucoup parlé sur LinuxFr.org et qui a toujours besoin d’aide.
Aller plus loin
- Annonce officielle de GIMP 2.10.2 (358 clics)
- GIMP 2.10 roule au GEGL (dépêche de la version précédente) (231 clics)
# Typo du NDM
Posté par azerttyu (site web personnel) . Évalué à 3.
Salut
Pour ne pas commencer avec juste un commentaire de type Typo :)
Merci encore pour cette dépéche de qualité. Ravi de voir Gimp dans de bonnes mains avec une belle cure de jeunesse.
Autrement je crois qu'on a un petite faute de frappe dans le NDM final. Il manque un e dans "Aryeom" :)
[^] # Re: Typo du NDM
Posté par patrick_g (site web personnel) . Évalué à 4.
Corrigé.
# Limitations du flatpack
Posté par yv_2000 . Évalué à 8. Dernière modification le 25 mai 2018 à 15:36.
Merci pour le travail ayant mené à cette mise à jour, et pour la dépêche nous en dévoilant les secrets.
Dans la page de téléchargement, je suggérerais que vous mettiez un lien ou une bulle d'information à "known limitations" dans "The flatpak build is new and has known limitations, though it will likely provide faster updates, following GIMP releases closely." expliquant quelles sont ces limitations (celles que tu as détaillées dans le corps de ta dépêche). Ainsi l'utilisateur saurait exactement les fonctionnalités qu'il va perdre en prenant le flatpack, et vous allez du coup probablement réduire le nombre de rapports de bug du type "Je n'ai plus accès à tel plugin avec la nouvelle version de Gimp".
En tout cas, ça fait plaisir de voir le pas rapide avec lequel Wilber est en train d'avancer, merci !
PS : Le paquet est déjà disponible chez debian sid.
[^] # Re: Limitations du flatpack
Posté par Jehan (site web personnel, Mastodon) . Évalué à 6.
On peut pas résumer/lister ces limitations dans une bulle d'information.
Il faudrait que je fasse un journal pour en parler (c'est prévu), et éventuellement faire un lien depuis gimp.org.
Les sandbox, c'est aussi beaucoup une évolution des logiques de conception des logiciels.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Commit de fusion ?
Posté par ff9097 . Évalué à 2.
Ça veut dire qu'une branche doit obligatoirement être rebasée sur master et que ça fusionne en fast-forward ? Je ne suis pas très fan de ce principe
[^] # Re: Commit de fusion ?
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
C'est surtout le mainteneur qui déteste les commits de merge, et ceci dit, je suis assez d'accord dans le cas de GIMP.
En gros, le but principal d'un commit de merge, c'est essentiellement "garder l'historique". Un commit doit garder son hash à jamais pour pouvoir être toujours retrouvable, histoire de ne jamais casser des liens ou rendre des discussions sur un changement particulier incompréhensible (car tu ne peux plus retrouver le commit discuté si le hash a changé).
Ça a beaucoup de sens sur de très gros projets avec énormément de contributeurs, etc. et surtout avec des branches de longue haleine. Par exemple si la branche principale est celle du mainteneur et chaque "lieutenant" (ou sous/co-mainteneur) a des branches (voire un remote) à lui, etc. Dans un tel contexte, on veut faire en sorte que toutes ces branches publiques à vie indéterminée gardent leur historique pour garder toute la cohérence.
Dans un projet comme GIMP avec 3 ou 4 développeurs permanents (et pas mal de gens externes qui font juste un patch par ci par là), qui bossent directement sur la branche
master, ça a beaucoup moins d'importance. Quand on fait des branches de fonctionnalités, en général, on peut souvent juste les supprimer après coup, histoire de faire un peu le ménage. Une fois mergées, elles ne sont jamais retouchées. Et de toutes façons, même quand elles sont encore actives, nos branches ont en général quasi qu'un seul développeur (sauf à la toute fin, quand une revue est nécessaire et que quelques corrections sont faites éventuellement).Dans ce cas, le seul intérêt du commit de merge est quasi complètement annihilé. Par contre ses défauts sont toujours là, et assez énormes: les commits de merge rendent un historique de commits vraiment illisibles. Je sais pas si tu as vraiment vu des arbres de commits (en vue non-linéaire) de gros dépôts, et notamment lorsqu'ils ont mergés des branches qui contenaient des dizaines de commits sur plusieurs mois. C'est juste une source de mal de tête.
Et je parle même pas de la vue linéaire (celle par défaut d'un
git log) qui est rendue totalement inutile dans ce cas.Dans notre cas hypothétique d'un gros projet dont la branche principale est quasi jamais développée directement et ne sert qu'à merger des branches publiques (qui elles accueillent du développement), c'est encore gérable. Mais un projet avec du développement quotidien et des commits de merge, c'est vraiment assez horrible.
Personnellement je ne serais pas contre des commits de merge sur certaines fonctionnalités de longue haleine qui ont nécessité des semaines ou mois sur une branche à part. Mais le monstre créé par les github/gitlab qui te font des commits de merge de partout pour un rien (genre: un patch de typo? Hop commit de merge!), c'est une aberration et surtout un abus complet du système et de la logique de git.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Lignes de code
Posté par Guillaume Maillard (site web personnel) . Évalué à -3.
Juste pour pour la migration de vers GTK3 ?
Euh.. comment dire…
https://informationisbeautiful.net/visualizations/million-lines-of-code/
[^] # Re: Lignes de code
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Je vois pas du tout là où tu veux en venir avec ce lien. J'ai l'impression que tu veux insinuer que c'est rien du tout, ce qui n'est peut-être pas du tout ton propos, mais tu nous excuseras d'extrapoler avec un message si limpide! :P
Si c'est le cas, d'une ce qui était intéressant dans ces nombres, c'est la comparaison "9 805 lignes de codes insérées pour 921 630 lignes supprimées". Un seul des nombres sans l'autre n'a aucun sens. En effet quand tu modifies une ligne de code par exemple,
gitcompte cela comme une insertion et une suppression de ligne. Donc 900.000 lignes supprimées en soi n'implique pas suppression de code. Par contre, le fait que ce soit accompagné de seulement 9000 lignes ajoutées, ça veut dire que 99% du changement sur cette branche dans le mois passé fut de la suppression (en gros). C'était essentiellement le taux qui était intéressant, pas le chiffre absolu.Deuxièmement, non, il ne s'agit pas du port complet (on n'a pas annoncé la sortie de GIMP 3, que je sache! :P), loin de là. C'est juste des stats sur environ 3 semaines de travail.
Troisièmement on ne réécrit pas le logiciel, on fait que le porter! Si on devait annoncer quelques millions de lignes supprimées, y aurait un problème!
Dernièrement c'était juste une petite stat marrante pour accompagner l'image (aussi marrante), et tirée directement de git. Ça vaut ce que ça vaut, c'est à dire pas grand chose. Y a ni analyse ni sens caché et subtile derrière.
Vraiment pas de quoi relever quoi que ce soit donc (surtout que je sais toujours pas ce que tu cherchais à relever). :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Lignes de code
Posté par Arkem . Évalué à 0.
Je peux me tromper, mais ce que je crois comprendre de son commentaire est tout l'inverse :
Le nombre de lignes supprimées pour le passage à GTK3 est très supérieur à la taille totale d'application peut-être anciennes, mais qui ont marqué leur époque, dont Photoshop 1 qui n'en fait pas plus de 15% environ…
[^] # Re: Lignes de code
Posté par Guillaume Maillard (site web personnel) . Évalué à 7. Dernière modification le 26 mai 2018 à 18:16.
900 000 lignes de code, je trouve cela juste gigantesque (c'est des années de travail à temps plein).
Faut-il comprendre de vos explications qu'il a eu 911825 (921630-905) lignes de code supprimées? modifiées?
De ce que je comprend sur https://www.openhub.net/p/gimp , le code actuel de Gimp représente :
- 817267 lignes de code
- 125212 lignes de commentaires
- 190860 lignes vides
D'où une certaine incompréhension (toujours présente).
[^] # Re: Lignes de code
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Ok, comme quoi, un commentaire, c'est plus clair quand on utilise des phrases complètes. ;-)
C'est vrai que ça fait beaucoup (même si j'ai pas pour habitude de regarder le nombre de lignes qui changent et que le nombre de lignes peut monter assez rapidement avec le code "boilerplate, etc.).
Je me souviens plus exactement comment j'ai fait ces stats y a quelques jours, mais en essayant d'en refaire maintenant avec git diff, je trouve:
Le premier commit est le premier commit du 28 avril 2018 pour le port GTK+3, le second étant le premier commit du 20 mai (jour de sortie de GIMP 2.10.2). La différence de compte doit venir que j'ai pris un autre commit de fin (comme j'ai préparé la news en avance bien sûr, un plus vieux commit), mais globalement les chiffres restent similaires (je voulais vérifier au cas où j'ai fait une faute en copiant!).
Comme tu as éveillé tout de même mon esprit critique, j'ai regardé en détail le diff. Et tu as raison, c'est trop! En fait y a une suppression d'un SVG compté par git comme 872001 lignes supprimées à lui-seul! Clairement ça plombe les stats et c'est pas du code. On tombe à 50.000 lignes supprimées pour 10.000 insérées. C'est sûr, c'est pas pareil! :-)
Bon on reste à une insertion pour 5 suppression, mais c'est moins qu'une pour 100.
Merci de faire remarquer. C'est tout de suite mieux quand tu fais des commentaires avec du texte dedans, tu vois! :P
D'ailleurs si les admins de linuxfr veulent corriger, c'est avec plaisir!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Lignes de code
Posté par Benoît Sibaud (site web personnel) . Évalué à 8.
Précision ajoutée dans la dépêche.
# bravo et merci
Posté par makapuf2 . Évalué à 7.
tout est dans le titre, bravo et merci de faire évoluer ce logiciel utile à tout le monde !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.