Sommaire
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 par 14 contributeurs ;
31 commits sur le dépôt de babl par 6 contributeurs ;
229 commits sur le dépôt de GEGL par 33 contributeurs ;
1179 commits sur le dépôt de ctx 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 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 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, à 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, mais puisque cette traduction a tardé, j’ai fusionné les deux nouvelles (la sortie et le compte-rendu de l’année) 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 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, 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 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.
GEGL, babl et ctx
Le cœur 🫀⚙️ du GIMP moderne est GEGL, 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, 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, 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 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, 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, macOS et Linux via Flatpak), une meilleure gestion des miroirs de téléchargement, une meilleure intégration continue 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 (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 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, 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 — 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 et Liberapay; 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 et Liberapay) 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.
Je vous souhaite à tous une merveilleuse année 2022. 🥳
