URL: https://linuxfr.org/news/compte-rendu-de-gimp-en-2021-et-sortie-de-gimp-2-10-30 Title: Compte rendu de GIMP en 2021 et sortie de GIMP 2.10.30 Authors: Jehan Pierre Maziere, Xavier Teyssier, Jona, vmagnin et palm123 Date: 2022-01-17T19:17:05+01:00 License: CC By-SA Tags: gimp et zemarmot Score: 5 Alors que 2022 a commencé, il est temps de revenir sur l’année 2021. Comme il s’agissait de ma première année en tant que co-mainteneur, j’ai décidé d’écrire ce compte-rendu en mon nom propre sur le [site officiel](https://www.gimp.org/news/2021/12/31/gimp-2021-annual-report/), me permettant ainsi un propos plus personnel sur ce que le projet GIMP représente pour moi. J’en profite pour annoncer la sortie (fin 2021) de la version corrective GIMP 2.10.30. !["Hello 2022" par Aryeom, Creative Commons by-sa 4.0 - GIMP 2021 annual report](https://www.gimp.org/news/2021/12/31/gimp-2021-annual-report/2021-12-wilber-and-co-year-end-party.jpg) *"Hello 2022" par [Aryeom](https://film.zemarmot.net), Creative Commons by-sa 4.0 - GIMP 2021 annual report* ---- [Compte rendu annuel de GIMP - 2021](https://www.gimp.org/news/2021/12/31/gimp-2021-annual-report/) [Sortie de GIMP 2.10.30](https://www.gimp.org/news/2021/12/21/gimp-2-10-30-released/) [Précédente sortie d'une version stable (2.10.28) sur LinuxFr](https://linuxfr.org/news/sortie-de-gimp-2-10-28-et-nouvelles-autour-du-projet) [Faire un don pour soutenir le projet GIMP et ses développeurs](https://www.gimp.org/donating/) [Télécharger GIMP](https://www.gimp.org/downloads/) ---- # Statistiques En 2021, nous avons eu : - **4 versions stables** (GIMP 2.10.24, 2.10.26, 2.10.28 et 2.10.30) ; - **2 versions de développement** (GIMP 2.99.6 et 2.99.8) ; - **1179** ***commits*** sur la branche de développement instable (2.99.x, la future 3.0) et **407** ***commits*** sur la branche de développement stable (2.10.x) du dépôt principal ; - **91 contributeurs** sur le dépôt principal, dont (certains appartiennent à plusieurs catégories) : * 41 développeurs ; * 42 traducteurs ; * 24 contributeurs de ressources (icônes, thèmes, documentation dans le dépôt de code) ou d’améliorations du système de compilation. - 22 personnes ont contribué plus de 10 commits dans le dépôt principal, parmi lesquels 2 contributeurs ont réalisé plus de 100 commits (Jacob Boerema et moi-même), parmi lesquels un seul (moi-même) en a réalisé plus de 500 ; - **247 _commits_** sur le dépôt du [site web de GIMP](https://www.gimp.org) par 14 contributeurs ; - **31 _commits_** sur le dépôt de [babl](https://gegl.org/babl/) par 6 contributeurs ; - **229 _commits_** sur le dépôt de [GEGL](https://gegl.org) par 33 contributeurs ; - **1179 _commits_** sur le dépôt de [ctx](https://ctx.graphics/) par 3 contributeurs (principalement Øyvind Kolås) ; - **255 _commits_** dans le dépôt `gimp-help` (notre manuel), dont le principal contributeur est Jacob Boerema qui fait un superbe travail de reprise ; - **53 _commits_** dans le dépôt `gimp-macos-build` (notre dépôt pour le système de build de macOS) par 4 contributeurs (principalement Lukas Oberhuber qui a repris la maintenance du paquet macOS) ; - **185 rapports de bogues corrigés** dans nos versions de 2021 et **des centaines** de plus gérés, triés, discutés et étudiés… ; - de nombreux correctifs réalisés par les contributeurs de GIMP dans divers autres projets que nous utilisons (GLib, GTK, Cairo, GExiv2 et d’autres… trop nombreux à citer) et d’innombrables rapports de bogues remontés par nos contributeurs à d’autres projets ; - **De l’aide offerte** à (ou **obtenue** par) d’autres Logiciels Libres quand nous le pouvons, par exemple au très sympathique projet [Siril](https://siril.org) pour le traitement d’images d’astronomie, et d’autres logiciels, parce que contrairement à ce que certains pensent, nous ne nous positionnons pas dans un marché ou une compétition ! Nous travaillons ensemble à construire un meilleur environnement de travail graphique ; - Et bien plus ! Au final, c’est un sacré travail qui vous est fièrement présenté par GIMP. Comme vous pouvez le remarquer, nous avons de belles contributions, et pourtant le cœur du développement est en fait toujours réalisé par une poignée de personnes puisque la plupart des contributions sont ponctuelles (sur 91 contributeurs, 69 ont réalisé moins de 10 commits, et parmi ceux-ci, 51 n’en ont réalisé qu’un seul). Je veux saluer [Jacob Boerema](https://www.jacobboerema.nl/en/) en particulier, qui est le plus gros contributeur sur la branche stable cette année, alors que, je dois admettre me concentrer davantage sur la branche instable, quitte parfois à négliger un petit peu la branche stable 😒 ! Merci Jacob ! 🤗 Et nous ne devrions jamais oublier `babl`, `GEGL` et le nouveau projet `ctx` par Øyvind Kolås, puisque ceux-ci constituent le cœur du moteur d’imagerie de GIMP, et sont considérés comme faisant partie intégrante du projet GIMP au même titre que l’interface elle-même. # Constituer une équipe agréable Vous avez peut-être remarqué une section récurrente dans les quelques dernières nouvelles, appelée "*Nouvelles de l’équipe*" dans laquelle nous listons les changements dans l’équipe, en particulier les nouveaux contributeurs à qui ont été donné plus d’accès sur le gestionnaire de bogues ou le dépôt de sources. J’essaie d’être de plus en plus proactif dans l’intégration de nouvelles personnes au sein de l’équipe principale. En effet, comme vous l’avez vu dans les statistiques, Jacob Boerema est le seul autre contributeur qui a réalisé plus de 100 *commits* en 2021, tandis que j’en ai réalisés un peu plus de 500. Je souhaite améliorer ce ratio pour augmenter le *bus factor* (nombre de personnes sur lesquelles repose la pérennité d’un logiciel, lequel est de 2 ou 3 en moyenne pour GIMP ces dernières années). L’équipe de GIMP a toujours été très accueillante, du moins depuis que j’ai commencé à contribuer en 2012 et c’est même la raison qui m’a fait rester. Je veux perpétuer cette tradition. Mon but est d’identifier plus rapidement les personnes à qui donner plus de responsabilités (notez que les compétences techniques sont importantes mais la sociabilité, autrement dit être une bonne personne et agréable avec les autres, est mon critère prioritaire). Bon, en vrai, c’est bel et bien une astuce diabolique 🦹 pour diminuer ma propre charge (notamment comme je constate que je n'arrive plus à développer autant que je le voudrais car je m'occupe de trop de sujets transverses et que j'ai trop de tâches de maintenance), mais je m’attends également à ce que cela rende les contributions au projet plus attrayantes 🎡 (d’expérience personnelle)! Remercions tout spécialement Jacob Boerema pour son travail sans répit sur l’amélioration de prise en charge des formats de fichier (et plus encore), Niels de Graef pour son aide inestimable et sa grande expertise de GTK, Luca Bacci pour son très joli travail sur la prise en charge des appareils de saisie, son aide sur Windows et son expertise GTK, Daniel Novomesky pour avoir fait de HEIF/AVIF et JPEG-XL des formats de première importance… N’oublions pas les contributeurs récurrents tels que Massimo Valentini, Lloyd Konneker… (que ferions-nous sans ces personnes qui n’abandonnent pas GIMP après tant d’années ?!) et les nouveaux arrivants prometteurs comme Stanislasv Grinkov. Maintenant, applaudissons nos empaqueteurs : Jernej Simončič fait partie de GIMP depuis aussi longtemps que je m’en souvienne, fabriquant sans accrocs les installateurs Windows, un coéquipier solide sur lequel s’appuyer ; l’histoire de macOS est plus chaotique et pourtant Lukas Oberhuber a fait un travail titanesque ces derniers mois, donc j’espère qu’il restera parmi nous ; du côté de Flatpak, Hubert Figuière est d’une grande aide également (et j’espère ~~secrètement~~ 🤫 qu’il prendra ma suite pour la maintenance de nos flatpak stable, *beta* et *nightly* !). Au final, GIMP, c’est beaucoup plus que ses seuls développeurs, c’est une communauté. Que ferions-nous sans les personnes qui aident à maintenir le site web, à trier les bogues, à gérer nos infrastructures et tout le reste ? Et n’oublions pas les traducteurs, si nombreux ! Je vous adore tous ! Désolé de ne pas citer tout le monde (si je vous ai oublié, ne le prenez pas mal, il y a juste trop de gens qui font du bon boulot parmi nous !). Quand j'en parle, je définis GIMP tout autant comme un logiciel communautaire qu’un Logiciel Libre, ou plus simplement j’appelle cela un **Logiciel Libre Communautaire**. Ce double concept est extrêmement important à mes yeux et c’est la raison pour laquelle j’aime GIMP et pourquoi Aryeom comme moi-même (du [projet ZeMarmot](https://film.zemarmot.net/), à partir duquel nos contributions majeures ont réellement débuté) sommes restés. C’est un projet d’humains qui se rencontrent et essaient de construire quelque chose de bien ensemble (même si les buts personnels de chacun peuvent différer). Tout fonctionne merveilleusement du moment que nous nous souvenons d’être bienveillants les uns avec les autres. 🤗 Donc, **à tous les contributeurs (quelles que soient leurs spécialités) qui ont aidé GIMP jusque-là, je veux dire un énorme merci ! GIMP est ce qu’il est grâce à vous !** 🙏 # GIMP 2.10.30 sorti juste avant noël Sur le site de GIMP, cette sortie avait une [dépêche dédiée](https://www.gimp.org/news/2021/12/21/gimp-2-10-30-released/), mais puisque cette traduction a tardé, j’ai fusionné les deux nouvelles (la sortie et le [compte-rendu de l’année](https://www.gimp.org/news/2021/12/31/gimp-2021-annual-report/)) pour LinuxFr. En bref, GIMP 2.10.30 est principalement une sortie corrective qui contient néanmoins quelques améliorations intéressantes de prise en charge de formats en particulier pour le format `PSD` (divers sous-cas du format nouvellement ou mieux gérés) et `AVIF` (utilisation de l’encodeur `AOM` de préférence à `rav1e` car les performances du premier ont été améliorées significativement dernièrement). Nous avons aussi continué à travailler sur la prise en charge améliorée des changements sur les environnements Windows, macOS et Linux/Wayland (car on le sait, tout n’est pas une nouvelle fonctionnalité ou une correction de bogues ; parfois on doit changer du code simplement pour suivre des changements perturbateurs en amont). # GIMP 3.0 en approche Avec quatre versions de développement déjà sorties, vous savez que nous travaillons très dur sur le futur : GIMP 3.0. Quelques fonctionnalités ont pris beaucoup de temps, principalement quand nous avons changé la logique du cœur du projet. Je pense en particulier au code de sélection multiple de calques. Le problème n’est pas le fait que sélectionner plusieurs éléments dans une liste serait difficile à implémenter, mais plutôt que l’ensemble des fonctionnalités de l’application ont toujours été implémentées avec le présupposé qu’il n’y a jamais plus d’un seul calque ou un seul canal sélectionné. Donc que se passe-t-il quand il y en a maintenant 2, 3 ou davantage sélectionnés ? Chaque fonctionnalité, chaque outil, chaque greffon et filtre doit être repensé pour ces nouveaux cas d’utilisation. C’est un travail énorme et cela fait deux ans que je m’y attelle cahin-caha, tout en continuant aussi le port vers GTK3 ou le développement d’autres fonctionnalités ainsi que les revues de code des autres contributeurs. Heureusement, ce travail sur la multi-sélection de calques/canaux approche de sa conclusion, sans pour autant être complètement fini. C’est donc un jalon important vers la sortie de GIMP 3.0. Au fait, une partie de ce travail a été de se débarrasser du concept d’"éléments enchaînés" (l’icône ⛓ dans la fenêtre ancrable `Calques`) en faveur de la sélection multiple (ainsi que la recherche et le stockage de sets de calques comme concept remplaçant la capacité à sauvegarder les calques enchaînés). Cette partie est également terminée. J’en parlerai davantage dans la dépêche de sortie de GIMP 2.99.10. ![Calques chaînés remplacé par recherche de calque](https://www.gimp.org/news/2021/12/31/gimp-2021-annual-report/2021-annual-report-multi-layer-replace-link.gif) *Calques enchaînés remplacés par recherche de calques + icônes de verrous déplacés — version de développement* Parmi les autres éléments bloquants que j’avais [listés il y a un an](https://www.patreon.com/posts/what-remains-to-40087754), nous avançons progressivement sur notre port GTK3 et la prise en charge de Wayland, ainsi que sur la stabilisation de l’API des greffons. J’espère que tous cela sera bientôt considéré comme étant dans un suffisamment bon état pour considérer publier une sortie "candidate" (*Release Candidate – RC*). D’un autre côté, l'[invasion spatiale](https://www.gimp.org/news/2020/11/06/gimp-2-99-2-released/#space-invasion) a été le parent pauvre de 2021 et est certainement le sujet sur lequel il nous faudra revenir très bientôt. Il en est de même pour la [platforme d’extensions](https://www.gimp.org/news/2020/11/06/gimp-2-99-2-released/#extensions). # GEGL, babl et ctx Le cœur 🫀⚙️ du GIMP moderne est [GEGL](https://gegl.org/), un projet de bibliothèque presque aussi vieux que GIMP lui-même, développé par les mêmes personnes, quand bien même la première [tentative d’intégration a seulement eu lieu dans GIMP 2.6](https://www.gimp.org/release-notes/gimp-2.6.html#gegl), et qui, depuis lors, fait doucement son chemin pour être le moteur principal derrière la plupart des manipulations de pixel dans le logiciel. Le développement de GEGL a été ralenti depuis 2019, mais principalement parce qu’il devient chaque jour plus stable, ce qui signifie surtout que le code se consolide. C’est donc une bonne situation. Maintenant, ce serait tout de même injuste d’oublier de parler des prises en charge récentes du modèle de couleur `CMYK` dans GEGL, ce qui signifie que nous sommes un pas plus proche d’une meilleure prise en charge dans GIMP. Une autre aventure excitante est le nouveau projet sur lequel travaille Øyvind Kolås : [ctx](https://ctx.graphics/), une bibliothèque de graphisme vectoriel. Bien sûr cela peut paraître futile si on développe une application de graphisme matriciel, mais il y a en fait beaucoup de sujets concomitants. Un de ces sujets est l’interface graphique elle-même qui est généralement rendue par des primitives vectorielles. Dans le cas de GTK, le rendu est produit via Cairo. Øyvind a beaucoup travaillé pour faire un rendu à la fois [plus joli et plus rapide](https://www.patreon.com/posts/gegl-vectors-ctx-53188476) que Cairo, ou au moins équivalent dans de nombreux cas. `ctx` inclue également la gestion des couleurs depuis le début tel une partie intégrante de la plateforme. Bien sûr `ctx` est en plein développement comme on peut le voir par le nombre de *commits*. Donc il faut garder raison et observer à ce stade, mais c’est certainement un projet intéressant puisque Øyvind est clairement un développeur R&D aguerri. Il y a d’autres choses pour lesquelles `ctx` est utile, telles que les quelques opérations de GEGL avec des composants vectoriels qui ont déjà été portées vers cette nouvelle bibliothèque (par ex. `gegl:fill-path`) et le rendu de texte aussi se fait dorénavant le plus souvent via des formes vectorielles (donc qui sait ce qu’il se passera quand nous améliorerons la prise en charge du texte ?). GIMP ne va pas se réorienter vers du graphisme vectoriel, mais nous pourrions parfaitement avoir plus de fonctionnalités basées sur du vectoriel dans l’avenir (quiconque suit un peu mon travail sur *ZeMarmot* par exemple sait que nous cherchons vraiment à améliorer les manières d’intégrer SVG dans GIMP, comme dans mon [expérimentation de calque-lien vers des images externes](https://www.patreon.com/posts/gimp-dev-report-39631718), non encore intégrée). Quand nous ferons plus de prise-en-charge vectorielle dans GIMP, `ctx` sera sans aucun doute une solution potentielle de choix. Je sais que Øyvind me dirait que `ctx` est en fait beaucoup plus vaste que ces quelques usages que j’ai résumés ici. Donc permets-moi de m’excuser à l’avance, Øyvind ! C’est la raison pour laquelle ce billet est en mon nom, assumant mes propres limitations dans la compréhension de tes plans futurs, et prêt à être agréablement surpris et étonné plus tard ! 🤯 # Infrastructures, documentation Dans tout projet logiciel, il y a une constante qui est pratiquement invisible, et pourtant extrêmement importante : l'infrastructure. Vous avez peut-être remarqué que nous en avons parlé un peu plus qu’à l’accoutumée en 2021 parce que certains manques m’ont toujours ennuyé dès mes premières contributions à GIMP. J’ai ainsi toujours regretté que nous n’ayons un système de construction de binaires distribuables plus solide, automatisé et transparent (ce qui est aujourd’hui le cas pour [Windows](https://www.gimp.org/news/2021/10/20/gimp-2-99-8-released/#automated-release-installers), [macOS](https://www.gimp.org/news/2021/12/06/gimp-2-99-8-for-macos/) et Linux via Flatpak), une meilleure [gestion des miroirs de téléchargement](https://www.gimp.org/news/2021/10/06/official-mirror-policy/), une meilleure [intégration continue](https://www.gimp.org/news/2021/10/20/gimp-2-99-8-released/#continuous-integration-changes) pour le développement et une meilleure documentation pour l’utilisateur final (sous l’élan de Jacob ces derniers temps ! Et nous prévoyons d’automatiser davantage la publication et la politique de test en ligne du manuel de GIMP, ce qui devrait voir le jour en 2022)… 2021 a également été l’occasion de réaliser des changements dans la documentation pour les développeurs : [Akkana Peck](https://shallowsky.com/) (bien connue pour avoir écrit des livres sur GIMP) et Lloyd Konneker ont aidé à mettre en place un début de documentation pour porter les greffons et scripts de la version 2.10 vers la version 3.0. Akkana a aussi aidé à mettre en place les règles de génération de références de l’API pour Python et JavaScript (avec `g-ir-doc-tool`). Plus récemment, Niels De Graef a migré la génération de notre documentation C des API depuis `gtk-doc` vers `gi-docgen`, produisant une documentation web beaucoup plus moderne pour les développeurs de greffons. Rien de cela n’est encore disponible en ligne mais seulement inclus dans le dépôt des sources pour l’instant. Mettre en place une procédure de mise à jour en ligne pour ces documentations est aussi sur la _TODO list_. ![Nouvelle documentation des API](https://www.gimp.org/news/2021/12/31/gimp-2021-annual-report/2021-annual-report-API-reference.png) *Nouvelle documentation d’interface pour les développeurs de greffons – version de développment* Tous ces sujets prennent beaucoup de temps et sont aussi nécessaires pour atteindre un niveau d’utilisation de GIMP plus agréable. Donc je suis déjà assez fier de ce que nous avons fait en 2021 et vraiment excité à propos de nos plans pour 2022. # Plans pour 2022 Vous vous demandez peut-être maintenant : quand est-ce que sortira GIMP 3.0 ? Et non, désolé, comme toujours, nous ne répondons pas à une telle question. 😛 Ce que je peux dire, c’est que nous y travaillons dur et je suis le premier à vouloir que cela advienne au plus tôt. Comme expliqué, hors le code en lui-même, le travail sur les infrastructures est aussi chronophage. Or je souhaite que nos nouvelles infrastructures de manuels en ligne ainsi que notre cadriciel web d’extensions soient prêts pour la sortie de GIMP 3.0. Idéalement je souhaite également mettre en place un tout nouveau site web pour développeurs avec de la documentation à jour. Donc les évolutions sont en fait assez nombreuses et il ne s’agit pas seulement du code du logiciel (qui n’est pas tout à fait prêt non plus, de toutes façons). N’oubliez pas que vous pouvez [donner au projet et personnellement financer plusieurs développeurs de GIMP](https://www.gimp.org/donating/), de manière à en valoriser et accélérer le développement. Comme vous le savez, moi-même en tant que mainteneur de GIMP et [Aryeom](https://linuxfr.org/news/interview-d-aryeom-dessinatrice-de-marmottes-mais-pas-que) — qui est, dans l’ombre, responsable d’énormément d’améliorations, design, tests et de nouvelles fonctionnalités — (tous deux via le projet *ZeMarmot*, notamment sur [Patreon](https://www.patreon.com/zemarmot) et [Liberapay](https://liberapay.com/ZeMarmot/); vous pouvez donc considérer ces comptes comme les comptes officiels de maintenance de GIMP, la majorité du code vient de là), de même qu’Øyvind en tant que mainteneur de GEGL (sur [Patreon](https://www.patreon.com/pippin) et [Liberapay](https://liberapay.com/pippin/)) sommes financés de manière participative pour pouvoir travailler à plein temps essentiellement sur du Logiciel Libre et de l’Art Libre. Tout financement est apprécié pour nous aider à voir ces efforts aboutir, car nous ne sommes toujours pas [pérennes](https://linuxfr.org/news/financer-les-developpeurs-de-gimp-pour-un-developpement-perenne). Je vous souhaite à tous une merveilleuse année 2022. 🥳