URL:     https://linuxfr.org/news/25-ans-de-gimp-et-version-de-developpement-2-99-2-premiers-pas-vers-gimp-3
Title:   25 ans de GIMP et version de développement 2.99.2 : premiers pas vers GIMP 3 !
Authors: Jehan
         orfenor, Pierre Maziere, BAud, HL, Snark, theojouedubanjo, Julien Jorge, antistress, Obi MO, Benoît Sibaud, ted, Yves Bourguignon, palm123 et olivierweb
Date:    2020-10-24T22:59:01+02:00
License: CC By-SA
Tags:    gtk3, wayland, hidpi, gimp, sortie_version, flatpak et gegl
Score:   5


GIMP a fêté ses 25 ans d’existence le 21 novembre 2020. Passé de petit projet d’étudiants qui l’ont abandonné du jour au lendemain à projet majeur incontestable du graphisme mondial qui a fait bouger les lignes du logiciel Libre… ce logiciel aura eu un impact sur le monde.



Peu avant cet anniversaire, la version de développement GIMP 2.99.2 est sortie le 25 octobre. Bien que ce ne soit qu’une version de développement, il s’agit de la première étape publique du chemin menant à GIMP 3 !



Nouveautés marquantes de GIMP 2.99.2 :



- Interface utilisateur maintenant en GTK3, incluant donc la prise en charge native pour Wayland et les écrans haute densité de pixels (HiPPI).
- Réorganisation et nettoyage du code
- Nouvelle interface de développement (*API*) pour les greffons
- Les greffons peuvent maintenant être écrits en Python 3, JavaScript, Lua, et Vala.
- L’invasion spatiale (colorimétrique) continue
- Cache de rendu pour des performances améliorées



![Splash screen de GIMP 2.99.2 par Aryeom, CC by-sa](https://www.gimp.org/news/2020/11/06/gimp-2-99-2-released/gimp-splash-2.99.2.jpg)
*Splash screen de GIMP 2.99.2 par [Aryeom](https://film.zemarmot.net), Creative Commons by-sa 4.0*



_Note de la modération : LinuxFR a la chance d’avoir parmi ses contributeurs : Jehan, très actif dans le développement de GIMP depuis quelques années déjà (entre [autres choses](https://linuxfr.org/tags/zemarmot/public)). Grâce à lui, non seulement vous découvrez les nouveautés de chaque version de GIMP dans la langue de ~~Molière~~ Gims, mais en plus vous lisez bien souvent une version enrichie de l’annonce initiale en anglais. C’est notamment le cas avec cette dépêche._

----

[Annonce de sortie de GIMP 2.99.2](https://www.gimp.org/news/2020/11/06/gimp-2-99-2-released/)
[Annonce des 25 ans de GIMP](https://www.gimp.org/news/2020/11/21/25-years-of-gimp/)
[Page de donation de GIMP](https://www.gimp.org/donating/)
[Projet ZeMarmot (dont fait partie l’auteur de l’article, développeur majeur de GIMP)](https://film.zemarmot.net/fr/)
[Dépôt de sources et suivi de bugs](https://gitlab.gnome.org/GNOME/gimp/)
[Dépêche précédente sur LinuxFr (GIMP 2.10.22)](https://linuxfr.org/news/gimp-2-10-22-consolidation-des-formats)

----

![Poster du film libre « Coffee Run » par Hjalti Hjálmarsson](https://www.gimp.org/news/2020/11/06/gimp-2-99-2-released/gimp-2-99-2-overview.jpg)
*GIMP 2.99.2 avec le poster du film [Coffee Run](https://cloud.blender.org/films/coffee-run) par Hjalti Hjálmarsson*



# Interface utilisateur en GTK3



La première différence est bien sûr visuelle, avec un sentiment d’interface un peu plus moderne, ainsi que l’utilisation possible de nouveaux éléments d’interface. Diverses boîtes de dialogue profitent aussi maintenant de décorations de fenêtre côté client. Cependant les différences esthétiques sont loin d’être l’attrait majeur de GTK3.



![GIMP 2.10.22 and 2.99.2 interfaces côté à côte](https://www.gimp.org/news/2020/11/06/gimp-2-99-2-released/gimp-2.10.22-2.99.2.jpg)
*Gauche : GIMP 2.10.22 - Droite : GIMP 2.99.2*



## Vraie prise en charge des écrans à haute densité de pixels



L’une des faiblesses majeures de GTK+2 est l’absence de prise en charge d’écrans à haute densité de pixels (par exemple de petits écrans avec une haute résolution ou de grands écrans avec une extrêmement haute résolution). Ces derniers ne sont pas majoritaires mais deviennent de plus en plus répandus, notamment chez les professionnels du secteur graphique. GIMP 2.10 avait une prise en charge limitée (dont j’étais d’ailleurs à l’origine de l’implémentation), comme une rustine de code, qui aidait dans certains cas intermédiaires mais n’était pas appropriée aux usages plus intensifs.



GTK3 fournit donc une vraie prise en charge dans GIMP qui suivra désormais les préférences système pour le redimensionnement d’interface.



*État* : fini.



## Prise en charge améliorée des périphériques d’entrée



Par « périphérique d’entrée », on entend surtout les tablettes graphiques et tablette-écrans. Ces périphériques étaient bien sûr déjà pris en charge, mais avec pas mal d’insuffisances jusqu’à GIMP 2. Notamment il fallait brancher la tablette avant de démarrer GIMP et l’activer explicitement dans les préférences du logiciel. Pire, débrancher la tablette en cours d’usage pouvait rendre GIMP instable (un problème que j’ai plus ou moins mitigé dans GTK+2, pendant la série 2.8, l’un de mes premiers [patchs majeurs](https://gitlab.gnome.org/GNOME/gtk/-/commit/8368de2bc35056d466f0a536eadc353c69c0e6e3) mais qui néanmoins n’est pas la solution idéale que nous apporte GTK3).



GIMP 3 (et donc cette version de développement aussi) nous permet ainsi le branchement à chaud. En d’autres termes: démarrez GIMP, branchez la tablette, c’est bon. Vous êtes maintenant paré pour dessiner avec prise en charge de la pression, de l’angle et de toute autre entrée du stylet.



L’une des choses que l’on souhaite améliorer maintenant est la simplification de la configuration avancée de ces périphériques d’entrée.



Pour ce qui est de la prise en charge des évènements tactiles multi-point (pour zoomer, faire tourner ou se déplacer sur le canevas par exemple), nous avons un peu expérimenté cela à un moment. Nous n’avons néanmoins pas achevé cela, car nous avons vite réalisé qu’il ne s’agissait pas d’une priorité en comparaison d’autres fonctionnalités.



Le tactile est une fonctionnalité très sympathique, mais elle peut aussi s’avérer gênante. D’ailleurs de nombreux artistes professionnels finissent par désactiver le tactile pour ainsi éviter des actions non voulues (au point que de nos jours, les tablettes haut de gamme tendent à sortir avec un interrupteur physique permettant de désactiver matériellement le tactile, même si on peut aussi le désactiver logiciellement). C’est pourquoi ce n’est pas une priorité. Nous ne savons donc pas si GIMP v3.0 sortira avec prise en charge des gestes multi-points. Bien sûr, nous accueillons avec plaisir tout patch de quiconque voudrait en faire sa priorité et ainsi s’assurer que GIMP ait cette fonctionnalité.



*État* : encore du travail à faire dans la simplification de la configuration des tablettes maintenant que certaines fonctionnalités historiques ne sont plus utiles ou peuvent être présentées de manière plus compréhensible. Il existe aussi des fonctionnalités spécifiques à Wayland pour les tablettes que nous pourrions ajouter en fonction du temps disponible et de l’intérêt exprimé.


## Personnalisation du thème



Nous héritons aussi bien entendu du système de thème de GTK3, basé sur le langage de style CSS. Cela signifie malheureusement que tous les thèmes personnalisés des versions passées ne seront pas compatibles avec GIMP 3.0 et les sorties futures. Le bon côté des choses est qu’il s’agit d’un standard bien connu et répandu, ce qui devrait rendre la personnalisation de l’interface de GIMP bien plus accessible à un plus grand monde.



De même, les thèmes d’icônes symboliques sont bien mieux pris en charge. Les couleurs s’adapteront aux couleurs de premier et arrière plans définies dans le thème. Si vous avez déjà changé le thème de GIMP 2.10.x, en passant d’un thème sombre à un thème clair, vous vous souvenez probablement que vous deviez aussi changer le thème d’icône manuellement. Ce n’est plus nécessaire vu que les icônes seront automatiquement recolorées en fonction de votre thème.



Enfin le « thème sombre » est un concept central de GTK3, ce qui signifie que même les décorations de fenêtre seront recolorées si le système de fenêtre le permet (voir la capture plus haut).



Notons aussi qu’un même thème peut proposer à la fois une variante sombre et claire. C’est pourquoi la page de préférences de *Thème* propose une case à cocher *« Utiliser la variante de thème sombre si disponible »*. De même, un thème d’icône peut proposer à la fois des versions symboliques et couleurs, ce pourquoi la page « Thème d’icône » propose la case à cocher "*Utiliser les icônes symboliques si disponibles*". Vous êtes ainsi libre de personnaliser GIMP selon vos préférences.



![Theme switching](https://www.gimp.org/news/2020/11/06/gimp-2-99-2-released/gimp-2.99.2-themes.jpg)
*Passer de la variante sombre à claire en cochant une case, ce qui recolore aussi les icônes symboliques*



*État* : en attente de contributeurs de thème.



Côté code, les changements relatifs à la personnalisation du thème sont finis, maintenant nous avons besoin d’un thème par défaut ! Vous pourrez remarquer que GIMP 2.99.2 ne liste qu’un thème “Système”, qui utilise donc principalement les couleurs de votre thème GTK système. Il s’agit donc d’une régression par rapport à 2.10 qui proposait des thèmes aux couleurs neutres (clair, obscur et intermédiaire). Nous souhaitons donc réintroduire un thème par défaut avec des variantes clair/obscur ainsi qu’un thème gris-intermédiaire.



Pour rappel, le problème principal des thèmes systèmes est qu’ils couvrent des cas d’usage “bureautiques” alors que le travail graphique nécessite des couleurs neutres, sans teinte, pour ne pas polluer sa perception des couleurs. C’est la raison principale pour laquelle GIMP vient désormais avec un thème neutre et des icônes symboliques.



Bien entendu, les thèmes et icônes colorés sont toujours utilisables. D’ailleurs nous sommes certains que la communauté créera très rapidement de jolis thèmes personnalisés. Une très bonne manière de contribuer à GIMP sans être développeur !



## Prise en charge de Wayland



Le portage vers GTK3 devrait théoriquement nous permettre de bénéficier sans rien avoir à faire de la prise en charge de Wayland sous Linux. C’est presque le cas, mais pas tout à fait. Malheureusement, quelques bugs ont déjà été rapportés pour GIMP tournant sous Wayland. Certains d’entre eux sont clairement bloquants pour une publication de GIMP 3 (comme des comportements étranges de l’interface graphique ou d'[énormes fuites mémoire](https://gitlab.gnome.org/GNOME/gimp/-/issues/4092)). D’autres sont moins sérieux mais quand même gênants, comme celui où l’écran d’accueil est trop grand sur des affichages HiPPI parce que Wayland ne rapporte pas proprement la mise à l’échelle.



À moins que ces problèmes ne soient résolus, nous ne pensons pas pouvoir affirmer que la prise en charge de Wayland nous convient. Nous serons reconnaissants pour tout correctif pour y remédier, qu’ils soient envoyés à GIMP, GTK ou toute partie concernée de la pile technologique. Si l’idée de nous aider vous intéresse, voici la [liste de bugs concernant Wayland](https://gitlab.gnome.org/GNOME/gimp/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Environment%3AWayland).



Une prise en charge convenable de Wayland signifie également que quelques fonctionnalités doivent être réimplémentées à travers ce que l’on appelle des portails. Nous avons déjà fait cela pour le greffon de capture d’écran (qui utilise les portails Freedesktop, GNOME et KDE), et il y a également un travail en cours pour corriger la sélection de couleur à l’écran (fonctionne déjà sur KDE, pas encore avec les portails GNOME et Freedesktop; malheureusement Wayland vient avec pas mal de duplication de travail en fonction des bureaux).



Quant au portail des fichiers, c’est probablement quelque chose qui n’arrivera pas pour GIMP 3.0 parce que certaines fonctionnalités de la boîte de dialogue de fichier GTK restent indispensables. Mais ça pourrait être proposé plus tard à l’occasion de la refonte planifiée du mécanisme d’exportation.



Enfin il faut savoir que Wayland a actuellement une prise en charge inexistante de la correction de couleurs, c’est d’ailleurs une très grosse cause de conflit actuellement entre certains utilisateurs de logiciels de graphisme sous Linux et les développeurs de Wayland. Il faut donc savoir que même si GIMP tournait très bien sous Wayland, les serveurs Wayland ne sont pas encore utilisables pour un usage graphique professionnel, et ce au niveau protocolaire.



*État* : quelques bugs bloquants en particulier requièrent une attention. Les contributions sont bienvenues.



### Les « portails » ?



Propos de Jehan extrait du *chat* de rédaction de la dépêche pour qui veut en savoir plus sur ce que sont les portails :



> Les portails sont un changement de paradigme qui vient avec Wayland et les empaquetages comme Flatpak. Il implique de revoir la logique de certaines interactions. On y viendra, on a déjà réfléchi depuis des années à des changements dans le concept d’export notamment qui pourront aller avec ce changement de paradigme.
> Les portails sont un concept de « services du bureau Linux » (techniquement simplement un service D-Bus) pour diverses fonctionnalités : au lieu d’accéder directement aux services bas niveau (serveur d’affichage, système de fichiers, etc.), on demande à un service « je veux ça ». En l’occurrence, on demanderait au service « on veut ouvrir un fichier », puis on perd la main et on attend une réponse du service (entre-temps, le service aura probablement montré un sélecteur de fichier à l’utilisateur, lequel aura sélectionné un fichier, mais l’application ne connaît pas le détail).
> Ça va avec les nouveaux systèmes de permissions qui font progressivement leur entrée dans Linux. À terme, l’idée est qu’une application ne voit plus aucun fichier, ne peut plus accéder au réseau sans le faire savoir, ne voit pas les autres applications ni ce qu’il y a sur l’écran, etc.
> C’est intéressant niveau sécurité mais apporte énormément de limitations. Pour un usage avancé, les possibilités des portails sont encore très très limitées parce que ça permet d’ouvrir *un* sélecteur de fichier. On ne sait pas lequel. Ça peut en effet être le sélecteur GTK comme celui de Qt, celui de Windows ou de macOS, etc. Donc ça veut dire qu’on ne peut plus personnaliser cette boîte de dialogue.
> Typiquement les autres types de portails qui seraient à gérer par une application complexe (telle que GIMP) sont : les captures d’écran (image voire vidéo), la sélection des couleurs à l’écran, les périphériques d’entrée/sortie (imprimantes, scanners, webcams…), la gestion des écrans (une application sous Wayland ne sait plus sa position et n’a plus la possibilité de choisir sa position à l’écran, ni même ne sait combien d’écrans il y a, ou ne connaît les profils de couleurs, ce qui est d’ailleurs un gros problème pour les logiciels graphiques qui ne peuvent être utilisés professionnellement sous Wayland, etc.), l’accès au réseau, la communication avec les autres applications, etc.



# Sélectionner plusieurs calques à la fois



Gérer un projet complexe contenant des dizaines ou des centaines de calques est devenu beaucoup plus facile grâce à la possibilité de sélectionner plusieurs calques à la fois. La réalisatrice de dessins animés [Aryeom](https://film.zemarmot.net/) réclamait cette possibilité depuis 2015 et son projet *ZeMarmot* en a donc pris en charge le développement. Nouvel exemple de la collaboration fructueuse entre artiste et développeur : chaque détail a été précisé après discussion et a d’abord été testé en production.



![Selecting multiple layers in Layers dockable](https://www.gimp.org/news/2020/11/06/gimp-2-99-2-released/gimp-2.99.2-multi-layer-selection.png)
*4 calques sélectionnés, prêts à être déplacés ou transformés en même temps*



On peut sélectionner plusieurs calques dans la fenêtre des calques avec les combinaisons de touches classiques (`Shift+click` pour une série de calques et `Ctrl+click` pour sélectionner ou désélectionner). On peut réorganiser les calques par série : déplacer, réordonner, supprimer, dupliquer, fusionner, etc. tous les calques sélectionnés d’un coup.



Plusieurs outils fonctionnent sur tous les calques sélectionnés. Par exemple les outils de transformation (déplacement, rotation, échelle, perspective, transformation unifiée…)  transformeront tous les calques sélectionnés (en plus des calques liés par l’icône de chaîne). On peut aussi découper plusieurs calques d’un coup ou copier-coller une projection de calques fusionnés. L’outil _pipette_ peut même prendre un mélange de couleurs réparties sur plusieurs calques (similaire à l’option "*Échantillonner sur tous les calques*" en version partielle, c’est-à-dire sans avoir à masquer les calques non-désirés).



Il ne s’agit que de quelques exemples parce qu’une grosse partie du code est impactée par ce changement : le concept d’un seul calque actif est omniprésent dans les actions. Vous en apprendrez plus en lisant [le rapport de développement](https://www.patreon.com/posts/report-on-for-in-37266151).



*État* : bien avancé, mais toujours en cours.



Quelques outils fonctionnent encore en calque unique et doivent être modifiés avant la version finale. Ce faisant, nous casserons probablement des choses, c’est pourquoi nous sortirons d’autres versions de développement. De plus, nous pourrions bientôt étendre la sélection de plusieurs éléments aux chemins et canaux.



Enfin, la peinture et les opérations GEGL (filtres) sont encore limitées aux calques uniques. Permettre de peindre ou de retoucher des pixels sur plusieurs calques à la fois, nécessite probablement des changements d’interface (à concevoir) pour éviter les effets indésirables, comme des opérations trop longues ou qu’on ne pourrait annuler.



# Interface de programmation (*API*) pour les greffons



Nous avons dû briser l’interface de programmation pour les greffons afin d’introduire beaucoup d’améliorations, tout en faisant attention à ne pas briser ce qu’il n’y avait pas lieu d’être.



Porter un greffon constitué d’un seul fichier de GIMP 2.10 à GIMP 3 prend d’habitude entre 5 et 30 minutes. Nous travaillons à l’écriture d’une documentation de portage, qui sera publiée en même temps que GIMP 3.



Si vous êtes un développeur de greffons, une des premières étapes à suivre est de s’assurer que vous n’utilisez pas de fonctions obsolètes. Nous avons compilé une [liste de fonctions retirées avec leur remplacement](https://gitlab.gnome.org/GNOME/gimp/-/blob/master/devel-docs/GIMP3-plug-in-porting-guide/removed_functions.md). Vous pouvez déjà effectuer cette partie du portage tout en ciblant les versions GIMP 2.10.x.



## API orientée Objets



Parmi les changements notables, nous avons écarté les identifiants d’objets (_object IDs_) pour utiliser directement des objets. En particulier dans GIMP 3, `GimpImage`, `GimpItem`, `GimpDrawable`, `GimpLayer`, `GimpVectors`, `GimpChannel` et `GimpPDB` sont des objets (d’autres classes d’objets existent déjà ou pourraient être ajoutées plus tard).



Cela permet une programmation plus sécurisée en ayant des objets typés dont la classe peut facilement être vérifiée, et donc implique des messages d’erreur plus adaptés (avec les _IDs_, qui sont simplement des nombres entiers, il n’était pas rare d’avoir des bogues bizarres à cause d’_IDs_ incorrectes, compliquant la recherche de bogues).



La programmation objet amène également l’héritage de classes. Typiquement, une `GimpLayer` est aussi une `GimpDrawable`, elle-même étant une `GimpItem`. Cela signifie que vous pouvez utiliser n’importe quelles méthodes des classes parentes et facilement savoir à quelle classe elles appartiennent.



Une conséquence non-C est que cela permet des ponts pour adapter les API à leur propre modèle objet. Ainsi, dupliquer une instance `GimpImage` nommée par exemple `img` en Python 3 peut être fait avec l’API assez pythonesque `img2 = img.duplicate()`.



*État* : le portage objet est quasi terminé. Nous voulons également utiliser la signalisation objet, qui est en cours de réalisation et devrait au final permettre de connecter des gestionnaires de signaux directement aux objets pour gérer des évènements venant du cœur de l’application (chose impossible dans GIMP 2, sauf à lancer des requêtes périodiquement).



## Usage de GIO pour la gestion des fichiers



Un autre changement dans l’interface de programmation des greffons (*API*) est l’usage de `GFile` pour abstraire les fichiers, c’est-à-dire donc avec GLib/GIO.



Cela peut paraître un peu ennuyeux au premier abord (cela peut ajouter une étape additionnelle de création et de gestion de `GFile`), néanmoins cela permet une gestion des fichiers plus robuste. En particulier, il n’est plus nécessaire de se préoccuper du codage des chemins d’accès et de conversions (un problème lorsque les développeurs supposent que tout le monde utilise le même codage) et donc moins de chemins erronés et de code non-portable. En outre, on n’a plus à se poser la question des schémas de notation de chemins différents entre systèmes d’exploitations (tels que le caractère de séparation de répertoire ou les notations de système de fichier). Travailler avec des `GFile` rend la représentation interne d’un fichier transparente, donc l’usage d’un fichier plus robuste.



Un autre avantage majeur est que l’interface obtient automatiquement toutes les capacités des modules GIO installés, tels que le chargement/enregistrement sur des URI distantes (et possiblement à travers des canaux chiffrés comme HTTPS). Cela ouvre donc des possibilités sans code spécifique côté applicatif.



L’usage de GIO pour le traitement de fichier avait déjà été fait dans le code principal de GIMP pour la sortie initiale de GIMP 2.10.0. Nous permettons maintenant aux dévelopeurs de greffons d’en profiter également dans GIMP 3.0.



*État*: terminé, excepté pour les *bindings* historiques.



Les *bindings* nouvelle génération par introspection `GObject` ont un accès complet à l’interface `GLib`/`GIO` et sont donc parfaitement capables de créer des `GFile` à travers des chemins d’accès et des URIs. Par contre les *bindings* historiques, tels que `script-fu` (Scheme), n’ont pas accès à l’API `GFile`. Nous devons travailler sur ce sujet (un patch existe même déjà mais a besoin de revue de code).



## Déclaration des greffons



L’interface de programmation des greffons a connu une refonte majeure dans les fonctions de déclaration du greffon. Cela se fait maintenant en sous-classant une classe `GimpPlugIn` et en re-définissant certaines méthodes pour lister et documenter les procédures créées par le greffon. Cela permet une déclaration bien plus propre, explicite et évolutive que l’interface précédente, et cela devrait donc aider les développeurs de greffons.



La manière dont les paramètres des procédures de vos greffons sont maintenant gérés a également été standardisée, en particulier en utilisant les propriétés `GObject` d’un objet de configuration. C’est plus facile à gérer en tant que logique générique. En particulier, le même objet de configuration nous permet  de générer de nombreuses fonctionnalités. Par exemple, il aidera à générer des dialogues à la demande pour des greffons qui ne veulent pas *tripatouiller* du GTK ou un autre toolkit par eux-mêmes. Cela simplifie également et standardise la sauvegarde de paramètres pour des appels ultérieurs ou une même procédure.



Au final, cela fait également partie du travail de fond pour une future fonctionnalité d’enregistrement de macro (très peu probable de la voir dans GIMP 3.0, mais c’est une partie du travail amenant à cette fonctionnalité puisque nous serons capables de sauver de manière fiable les paramètres utilisés lors du lancement des greffons.



*État* : bien que la partie principale de cette API soit terminée, la version finale nécessite d’autres ajustements, comme la représentation des paramètres qui n’est pas encore figée.



## Prise en charge de langages de programmation variés (*bindings*)



L’interface de programmation (*API*) est maintenant entièremement *introspectée* grâce à [GObject Introspection](https://gi.readthedocs.io/en/latest/). Cela implique que GIMP peut maintenant être scripté avec une large variété de langages informatiques. Voici ceux que nous avons testé à ce jour, et dont nous pouvons donc confirmer la viabilité (en plus de C et C++ bien sûr) :



* Python 3
* JavaScript
* Lua
* Vala



L’une des principales différences avec l’ancienne méthode pour faire des interfaces intermédiaires pour scripter GIMP (par exemple GIMP 2.10 avait une interface Python 2) est que nous ne nécessitons plus de couche logicielle intermédiaire. C’est donc un énorme gain en maintenance et en stabilité.



En outre les interfaces non-C de GIMP 2 se basaient habituellement sur le protocole de communication de GIMP appelé `PDB`, lequel n’est en fait qu’un sous-ensemble des fonctionnalités de la bibliothèque C `libgimp`. Au contraire, les nouvelles interfaces sont générées à partir de `libgimp` même, par conséquent les greffons en Python 3, Javascript, Lua ou Vala (ainsi que toute future prise en charge par introspection) auront les mêmes possibilités d’action que les greffons en C. C’est un nouveau monde qui s’ouvre aux développeurs de greffons GIMP !



Une autre conséquence est que les interfaces résultantes sont globalement les mêmes dans tous ces langages de programmation, aux spécificités de syntaxe près.
Par exemple, si pour trouver l’intersection d’un `drawable` avec une sélection se fait ainsi en C :



```C
success = gimp_drawable_mask_intersect (drawable, &x, &y, &width, &height);
```











En Javascript, ce sera :



```js
let [ intersect, x, y, width, height ] = drawable.mask_intersect();
```











En Python 3:



```python
intersect, x, y, width, height = drawable.mask_intersect()
```











Un autre exemple sympa est la manière dont les tableaux C avec paramètre additionnel de longueur sont gérés dans les langages qui ont une structure de données appropriée (et en particulier ne nécessitant pas l’information de longueur dans un argument à part).
Ainsi alors que vous copiez les pixels de multiples *drawables* ainsi en C :



```C
/* Where @drawables is a C array of drawables, and @num_drawables
 * indicates the size of this array.
 */
gimp_edit_copy (num_drawables, drawables);
```











En Python 3, vous faites la même chose avec une liste Python, laquelle n’a pas besoin de l’argument `num_drawables` maintenant redondant avec les possibilités de la structure liste Python :



```python
Gimp.edit_copy([drawable1, drawable2, drawable3])
```











Bonus : non seulement les greffons non-C ont maintenant accès à toutes les fonctions proposées par GIMP, mais ils ont aussi accès à bien d’autres interfaces qui sont utilisées comme dépendances de GIMP. Ainsi un greffon peut utiliser n’importe quelle fonction de GLib/GIO, GTK, Pango, Cairo mais surtout babl et GEGL (ouvrant de nouvelles portes pour la manipulation de pixels et l’accès à une belle liste d’opérations graphiques). C’était probablement une des plus grosses limitations de l’interface Python 2 précédente, laquelle n’avait pas la possibilité de manipuler les pixels avec GEGL.



*État* : certains des développeurs ont regretté des fonctions spécifiques à l’ancienne interface Python 2, et en particulier la capacité de créer des dialogues simplement (sans utiliser GTK directement). Cette possibilité n’est pas dans GIMP 2.99.2 mais existera bien dans GIMP 3.0. En fait, après la sortie de GIMP 2.99.2, j’ai déjà ré-implémenté cela avec plus de fonctionnalités (c’est-à-dire des moyens de personnaliser l’organisation visuelle des options dans la boîte de dialogue notamment). Ce sera donc disponible dès GIMP 2.99.4 et sera extrêmement plus puissant que ce que l’interface Python 2 proposait.
Mais **surtout** : ce sera disponible à tous les langages, pas juste Python ou Scheme ! C’est l’un des autres gros avantages d’interfaces générées par introspection. Au lieu d’implémenter des supers fonctionnalités dans chaque couche de langage (similairement mais avec une implémentation et des possibilités différentes), on les fournit sur l’interface de base en C. En conséquence, tout développeur   --   quel que soit son langage de prédilection  --   aura accès à toutes les fonctionnalités.



Enfin, notons que `Script-fu` ne fait pas partie des interfaces générées par introspection (bien qu’il existe des interfaces *GObject Introspection* pour Scheme, mais nous ne les avons pas encore testées) et fonctionne donc encore avec une couche d’extension supplémentaire, « à l’ancienne », avec toutes les limitations que cela implique. En outre, des problèmes à cause du changement d’interface ont déjà été soulevés (notamment l’impossibilité de créer des `GFile` comme mentionné plus haut). Nous devrons régler cela d’ici la sortie de GIMP 3.0.



## Greffons _goat exercise_ (« promenade de chèvre »)



Pour chacune des interfaces de langages testées, nous avons créé un greffon appelé *promenade de chèvre* (*sic* - terme utilisé dans la traduction française officielle), lequel est une démo de création de greffon. C’est comme un *Hello World!* mais pour GIMP.



_NdT : Goat est une blagounette avec GEGL dont l’acronyme alternatif (« Genetically Engineered Goat, Large ») décrit son logo, [une chèvre à cinq pattes](https://fr.wikipedia.org/wiki/Fichier:GEGL.png)._



Chaque _promenade de chèvre_ fait exactement la même chose dans son propre langage : elle crée une fenêtre de dialogue avec un label, des boutons et une _text view_ (démo GTK+ et GLib/GIO) ; un des boutons déclenche un filtre modifiant le calque sélectionné (démo GEGL et démo GIMP API) ; tout cela pendant qu’elle montre son propre code source à l’intérieur de la _text view_ (facilitant ainsi l’inspection de code depuis GIMP) et avec un bouton vous envoyant vers le fichier du dépôt (si vous préférez récupérer la dernière version, confortablement dans votre éditeur de code).



![Promenade-chèvre dans 5 langages](https://www.gimp.org/news/2020/11/06/gimp-2-99-2-released/gimp-2.99.2-goat-exercises.jpg)
_Les 5 versions du greffon_ promenade de chèvre _en Python 3, Javascript, Lua, C et Vala_



Ces greffons sont assez importants puisque nous prévoyons d’améliorer l’écosystème des greffons avec GIMP 3. Il constitue la première étape de greffons de démonstration auto-documentés (tout en faisant quelque chose d’un peu plus intéressant qu’un simple « Hello World »).



*État* : le code actuel des _promenades de chèvres_ n’est pas toujours synchronisé avec les API les plus récentes puisque ce sont des éléments en constante évolution. Ils seront mis à jour avant la sortie finale.



## Documentation de développement



Nous avons commencé à mettre par écrit de la documentation concernant le développement de greffons dans GIMP 3, et commencerons à publier progressivement quelques didacticiels. Nous espérons même être capable de remettre à flot notre site web pour développeurs qui a doucement sombré depuis de trop nombreuses années. Nous espérons que GIMP 3 viendra redonner un coup de fouet à l’écosystème des greffons de GIMP.



*État* : encore à un stade précoce, nous souhaitons la bienvenue à plus de contributeurs pour rendre cela possible.



# Extensions



Les extensions sont un nouveau format de fichier qui est simplement un regroupement de données (brosses, écrans d’accueil, motifs, dynamiques…) ou de greffons, associés à des méta-données (nom, description, copies d’écran, version, pré-requis…). Le but sera de permettre aux développeurs de greffons de publier leurs travaux sur des dépôts pour que tout le monde puisse chercher des greffons venant de tiers, les installer ou désinstaller, activer ou désactiver, et les mettre à jour directement dans GIMP.



Le menu `Edit > Manage Extensions` montre la fenêtre principale de dialogue. Dans l’onglet « System Extensions » en particulier, vous noterez « Official Demo Plug-ins » qui est notre première extension. Elle regroupe en fait toutes les greffons Promenades-chèvres dont nous avons parlé plus haut. Si vous le désactivez, vous remarquerez après un redémarrage (pour le moment, vous devez redémarrer GIMP pour en voir les effets) que le menu catégorie `Filters > Development > Goat Exercises` aura disparu.



![Une extension Promenade-chèvre](https://www.gimp.org/news/2020/11/06/gimp-2-99-2-released/gimp-2.99.2-goat-exercise-extension.png)
*Les promenades de chèvres sont elles-mêmes notre première démo d’extension.*



Nous reviendrons sur cette fonctionnalité après que nous y aurons travaillé davantage. En particulier, nous fournirons de la documentation sur la manière de créer des extensions. C’est vraiment quelque chose que les créateurs de greffons et de ressources devraient garder en ligne de mire, puisque cela les aidera à partager leurs créations avec d’autres.



*État* : encore plus de travail à faire du côté de GIMP, particulièrement pour communiquer à propos des dépôts, et beaucoup plus de travail encore pour le dépôt officiel et le site web des extensions.



# L’invasion spatiale



"*Space invasion*" est le nom de code interne du travail initialement entamé en [2018](https://www.gimp.org/news/2018/08/19/gimp-2-10-6-released/#prepare-for-the-space-invasion) dont le but était de mettre en place une prise en charge adaptée de l’espace colorimétrique sur l’ensemble du traitement des pixels. Dans les séries de GIMP 2.10, malgré une prise en charge de la gestion des couleurs dans le cœur du logiciel, les profils étaient quelquefois perdus pendant le traitement d’une opération et seulement réintroduits dans le résultat final, ce qui pouvait donner lieu à des valeurs erronées dans certains cas. 


Quiconque souhaitant comprendre plus avant ces problématiques peut lire l'[article de Øyvind Kolås](https://www.patreon.com/posts/20264674) et en particulier [la note de sortie détaillée de GEGL 0.4.6](https://gegl.org/NEWS.html#_gegl_0_4_6_2018_07_23) dans laquelle il explique tout cela très bien.


Quelques améliorations de ce travail ont déjà été progressivement rétro-intégrées à diverses versions de GIMP 2.10.x, mais GIMP 3.0 devrait être la sortie ultime pour laquelle nous espérons régler cela à 100%.



*Status* : la branche de développement est beaucoup plus avancée sur ce sujet que la série des versions 2.10, mais davantage de travail est nécessaire. Divers aspects de GIMP sont toujours limités aux seules valeurs sRGB que ce soit pour l’affichage ou le traitement.



# Cache de rendu



GIMP 3 a maintenant un cache de rendu qui conserve le résultat d’un changement d’échelle, la gestion des couleurs, des filtres d’affichage et des masques de canevas (pour les outils tels que _Fuzzy Select_). Cela donne une sensation de rapidité de l’interface en comparaison à la version GTK2 de GIMP.



Il y a maintenant également un paramètre _Zoom Quality_ dans _Preferences -> Display_. Quand il est positionné sur _Fast_, GIMP fera une interpolation au voisin le plus proche depuis le mipmap de niveau immédiatement supérieur au lieu d’un filtrage linéaire ou fenêtré. Cela donne un coup de pouce léger mais permanent à l’affichage et à l’ensemble des  modifications. Nous avons quelques idées pour améliorer cela davantage,  comme de remplacer les pixels interpolés rapidement par une interpolation de meilleure qualité (mais plus lente) après un certain temps.



*État* : fini.



# Règles d’import améliorées



L’option de **Politique de profil de couleur** propose dorénavant un nouveau choix : "*Convertir au profil colorimétrique RVB préféré*" et l’action par défaut “Convertir” de la fenêtre d’importation convertira l’image au profil préféré (s’il a été défini, autrement on se réfère au profil prédéfini sRGB). La conversion au profil prédéfini sera toujours disponible comme une action secondaire. Si vous voulez toujours travailler avec le même profil donné, vous pouvez ainsi définir ce dernier ainsi que le comportement par défaut du logiciel à l’importation.



De plus, une nouvelle **Politique de rotation** est proposé dans la fenêtre des Préférences, à côté de la *Politique de profil de couleur* (à la page `Préférences > Importation et exportation d’images`) avec 3 options : « Demander ce qu’il faut faire », « Rejeter la méta-donnée sans rotation », et « Effectuer la rotation puis rejeter la méta-donnée ».



![Import Policies](https://www.gimp.org/news/2020/11/06/gimp-2-99-2-released/gimp-2.99.2-import-policies-prefs.jpg)
*Politique de profil de couleur mise à jour et nouvelle Politique de rotation*



Les règles de rotation par méta-donnée étaient jusque-là gérées du côté des greffons d’importation, avec des fenêtres de dialogue générées par `libgimpui` et sauvées dans un _parasite_ global. Toute la logique et l’interface graphique ont été déplacées dans le cœur du logiciel, au côté de la « Politique de profil de couleur ». Ceci implique que les greffons n’ont même plus besoin de gérer cela puisque ça se passera désormais génériquement et automatiquement comme spécifié par l’utilisateur à chaque nouvelle importation.



*État* : fini.



# Curseurs compacts



Le _curseur compact_ fut introduit dans [GIMP 2.10.18](https://www.gimp.org/news/2020/02/24/gimp-2-10-18-released/#compact-sliders). Dans la série des 2.10, il a été laissé comme une fonctionnalité optionnelle qui pouvait être désactivée dans la fenêtre de *Préférences*. Dans GIMP 3, c’est maintenant l’unique choix possible, sans option.


![Compact slider](https://www.gimp.org/news/2020/11/06/gimp-2-99-2-released/gimp-2.99.2-compact-spin-scale.png)
*Nouveau curseur compact comme seule et unique option*



Remarquez que la couleur bleu clair sur la copie d’écran n’est pas un choix de notre fait : cette couleur est définie par le thème (or comme on le disait, on n’a pas encore de thème spécifique, il s’agit donc d’un thème système quelconque). Ce widget utilise les couleurs par défaut de `GtkProgressBar`. Elles peuvent donc être ajustées dans un thème personnalisé en changeant les couleurs de `GtkProgressBar` ou seulement les couleurs de ce widget en particulier (une fois de plus, bienvenue aux contributeurs de thèmes!).



_État_ : fini.



# Amélioration continue du code



Pendant que nous portions d’anciennes fonctionnalités et en implémentions de nouvelles, beaucoup de travaux connexes ont été faits sur la structure du code. De nombreuses parties du code principal ont été réorganisées pour une meilleure maintenance.



Bien que tout n’ait pas encore été porté, un travail de fond a été mis en place, tel que l’interface `GimpAction` pour ajouter une couche d’abstraction aux `GtkAction` (nous préparant à nous en  séparer réellement à échéance, ce qui est une des grosses parties restantes pour la migration vers GTK3).



De nombreuses autres parties sont constamment retravaillées et améliorées au cours d’un travail de fond incessant.



*État* : la réorganisation du code est une tâche constamment active, l’a toujours été et le sera toujours. Elle ne s’arrêtera jamais vraiment.



# Paquets téléchargeables
## Flatpak "*beta*" disponible



Cette version est disponible dans la branche “beta” de notre [paquet Flathub officiel](https://flathub.org/apps/details/org.gimp.GIMP), qui est une branche de publication masquée (vous ne trouverez pas cette information sur la page publique sur le site de Flathub). Voici la commande qui vous permettra d’installer GIMP 2.99.2 :



```
flatpak install --user https://flathub.org/beta-repo/appstream/org.gimp.GIMP.flatpakref
```










À partir de là, vous pourrez mettre à jour vers de nouvelles versions de développement dès qu’elles seront disponibles par ce biais (si votre bureau intègre Flatpak, il pourra même vérifier automatiquement de lui-même et les proposer).



Il faut noter que Flatpak ne permet qu’une seule branche visible à la fois pour une même application, de sorte que si vous avez installé à la fois les versions stable et de développement avec Flatpak, votre bureau ne montrera que l’un ou l’autre. Pour changer de branche visible, il faut lancer la commande correspondante parmi les deux proposées ci-dessous :



```
flatpak make-current --user org.gimp.GIMP beta
flatpak make-current --user org.gimp.GIMP stable
```











Certains ont aussi créé des raccourcis qui lancent explicitement la commande `flatpak
run org.gimp.GIMP//beta` (ou `stable` respectivement), comme solution de secours pour obtenir des icônes pour les deux versions.



## Windows



Comme d’habitude, nous proposons un installateur pour GIMP sous Windows, que vous trouverez sur la [page de téléchargement de développement](https://www.gimp.org/downloads/devel/).



Il peut manquer quelques fonctionnalités. En particulier, vous ne trouverez pas d’interface JavaScript sur le paquet Windows en raison de la complexité de certaines dépendances. Nous corrigerons ce souci dans de futures pré-versions en chemin vers GIMP 3.



## macOS



Notre empaqueteur pour macOS n’est toujours pas complètement revenu, donc malheureusement nous n’avons pas de paquet macOS officiel. Comme toujours, nous vous rappelons que GIMP est un logiciel libre développé par une communauté. Chacun peut devenir un mainteneur officiel, et avoir plusieurs contributeurs sur la question permet d’assurer une meilleure pérennité.



Si vous êtes intéressé, n’hésitez pas à nous contacter sur notre canal développeur sur [IRC](https://www.gimp.org/irc.html) : `#gimp`.



# Et ensuite ?



Comme vous le voyez, énormément de choses ont été faites (le fichier [`NEWS`](https://gitlab.gnome.org/GNOME/gimp/-/blob/4f201556967d9e7c868601698e9e3d957c1c27ea/NEWS#L46) donne bien plus de détails). Le gros du travail a déjà été fait. Ce qui reste maintenant est le peaufinage. Ce n’est cependant pas si simple, car les décisions finales et l’attention aux petits détails sont le plus difficile. Nous voulons publier un GIMP 3 d’envergure, et devons donc être particulièrement méticuleux. Voilà où nous en sommes et c’est pourquoi nous publions cette première version de développement.



Ce [rapport de développement](https://www.patreon.com/posts/what-remains-to-40087754) détaille assez précisément tout ce qui reste à faire, et vous remarquerez à quel point il suit vraiment de près les changements de GIMP 2.99.2. C’est notamment du côté de l’API   --   bien que la plupart des utilisateurs ne la voient pas   --   qu’il faut notamment s’assurer de ne pas faire d’erreur avant publication, car notre API devra rester stable tout au long de la série des 3.x. Une fois que ce sera fait, nous voudrons garder les interfaces de `libgimp` 3.0.0 inchangées à moins d’une exception (par exemple parce que nous découvrons des bogues qui rendent une fonction inutile). Cela nous prendra du temps.



Il y a certainement d’autres points sur lesquels de l’aide fera la différence, que ce soit dans les greffons, le code, l’interface utilisateur ou l’interface de programmation. C’est pourquoi nous avons besoin de plus de paires d’yeux pour résoudre autant de petits problèmes que possible.



# GIMP a 25 ans!



Il y a pas mal d’anniversaires ronds de logiciels libres dernièrement. Pour ne pas déroger à la règle, GIMP vient de [fêter ses 25 ans](https://www.gimp.org/news/2020/11/21/25-years-of-gimp/)!… un âge dont peu de logiciels encore en activité peuvent se targuer.



![“Joyeux 25ᵉ anniversaire GIMP!” par Aryeom, Creative Commons by-sa 4.0](https://www.gimp.org/news/2020/11/21/25-years-of-gimp/2020-GIMP-25-th-birthday.jpg)
*“Joyeux 25ᵉ anniversaire GIMP!” par Aryeom, Creative Commons by-sa 4.0*



*Note*: une [vidéo accélérée (*timelapse*) de ce dessin est disponible, avec commentaires](https://youtu.be/rvPQ5KtM6aY) audios (et textuels dans des sous-titres notamment français). J’aime particulièrement beaucoup les commentaires, car ils apportent un autre niveau d’implication et de réflexion sur ce qui peut sembler être juste un petit dessin irréfléchi pour beaucoup de gens.
Le fichier source du dessin (format de GIMP `XCF`, comme d’habitude sous licence Creative Commons by-sa 4.0, vous autorisant à étudier et modifier l’œuvre pour faire une œuvre dérivée!) est disponible sur la [page Patreon associée](https://www.patreon.com/posts/25-years-of-gimp-44863356).



## Un peu d’historique



En effet, c’est le 21 novembre 1995 qu’un étudiant, Peter Mattis [annonce pour la première fois](https://www.gimp.org/about/prehistory.html#november-1995-an-announcement) un logiciel appelé « The GIMP » (*the General Image Manipulation Program*, le “General” deviendra par la suite “GNU” et l’article "*the*" disparaîtra), et livre un premier code publiquement, développé avec son collègue Spencer Kimball. Notons que les 2 étudiants abandonneront rapidement GIMP (vers 1998), sans vraiment penser à la relève (je pense qu’ils ne s’attendaient pas à l’engouement que cela créerait), qui fut donc majoritairement développé par la communauté depuis.



D’ailleurs dans un [article récemment paru dans El Paìs](https://retina.elpais.com/retina/2020/12/18/tendencias/1608306962_883235.html), second plus gros journal papier d’Espagne et journal en ligne le plus lu en langue espagnole, les 2 compères (maintenant beaux-frères) expliquent encore régulièrement utiliser GIMP même s’ils pensent qu’il n’y a probablement plus aucune ligne d’eux dedans de nos jours.
Je ne donne pas ce lien vers cet article au hasard, car il sort des centaines d’articles sur GIMP tous les ans, mais pour celui-ci (sorti il y a quelques jours), la journaliste nous a contactés (équipe actuelle de GIMP) ainsi que vraisemblablement les 2 auteurs originaux, et pour une fois on y trouve un vrai travail de synthèse journalistique (et pas juste du copier-coller de nos propres annonces). C’est appréciable de voir que le vrai journalisme 📰 existe encore! 🙂
Même s’il n’est pas en français, je conseille donc de lire cet article, car il donne un historique avec une vue et des données propres (si vous ne parlez pas espagnol, les traducteurs automatiques sont très performants de nos jours).


Dans les autres petites perles sur les auteurs originels, j’ai aimé [cette question finale à Spencer Kimball (à 57:03)](https://youtu.be/H-R8qgXxFb0?t=3422) dans une interview vidéo récente au sujet de son projet professionnel actuel (une base de donnée distribuée, donc peu de rapport avec du graphisme; apparemment [cockroachdb](https://github.com/cockroachdb/cockroach) est libre, les fondamentaux restent !). Je n’ai pas écouté l’interview complète, mais je me suis demandé ce que ce dernier considère en effet comme ce dont il est le plus fier. Ça ne manque pas : **à la question sur ce dont il est le plus fier dans sa carrière**, GIMP reste (et restera peut-être à jamais?) sa plus grande fierté:


> GIMP reste stable en favori. Ce n’est même pas que je suis si fier de ce que j’y ai fait. C’est le projet dans son ensemble. Ça fait 27 (*sic — note de Jehan: avaient-ils commencé à coder 2 ans avant la première sortie de code ? Pas impossible !*) ans. À chaque fois que je le télécharge, ou que j’ai un nouvel ordinateur, il est meilleur que la fois précédente. Il y a constamment des gens que je n’ai jamais rencontrés qui continuent à travailler dessus. Donc je suppose qu’être à l’origine de cela, en tant qu’auteur originel, c’est quelque chose qui me rend fier. Je pense que si ça avait été l’unique chose que j’avais faite dans ma vie, ça aurait été suffisant. Donc : GIMP.


Traduction personnelle d’après l'[original](https://youtu.be/H-R8qgXxFb0?t=3422):



> The GIMP remains a steady favorite to me. It's not even that I'm so proud of what I did on the GIMP. It's the larger project. It's been 27 (*sic*) years. Every time I download it, I get a new computer, it's better than the last time I downloaded it. There is always people out there I've never met that are working on it. So I guess, being behind them, as the original author, it is something that does make me quite proud and I feel like… if that's all I did in this life, that would be enough. So euh… GIMP.



Merci donc à ces derniers d’avoir démarré ce projet, même si c’était juste pour s’amuser en tant qu’étudiants !


Quoi qu’il en soit, nous y sommes, 25 ans après, des [centaines de contributeurs plus tard](https://www.openhub.net/p/gimp), du code à foison et des millions d’utilisateurs dans le monde. C’est en effet assez ébouriffant quand on y pense. C’est aussi l’un des rares logiciels de cette envergure qui est resté entièrement communautaire notamment dans son système de développement et de décision (un fait peu connu, je pense, et pourtant l’une des caractéristiques que j’adore chez GIMP et que j’espère qu’on pourra protéger aussi longtemps que possible).



## Un logiciel qui fait avancer tout le monde



Ce que j’ai toujours adoré avec GIMP, c’est aussi à quel point ce logiciel a eu un impact positif sur le logiciel libre. Pendant ces 25 ans, que s’est-il donc passé autour de GIMP ?


Le projet a créé la librairie graphique GTK (*GIMP Toolkit*), laquelle a donné naissance à plusieurs environnements de bureau (tels que GNOME, XFCE et d’autres) et des logiciels à ne plus pouvoir les compter. Cette bibliothèque est même possiblement la raison pour laquelle Qt est finalement devenu libre à son tour (on rappelle que Qt était propriétaire à ses débuts et c’est la raison pour laquelle des développeurs ont initialement extrait GTK du code de GIMP, le renommant au passage GTK+ avant de récemment revenir aux sources en l'[appelant à nouveau GTK](https://lwn.net/Articles/779305/)), afin de ne pas perdre la clientèle de tous les développeurs de logiciels libres, bien que cette supposition restera probablement à jamais spéculation (les décisions **réelles** d’entreprises étant rarement publiques).



Puis quelques développeurs du milieu de l’industrie du cinéma hollywoodien ont commencé à travailler sur un nouveau moteur graphique, [GEGL](https://gegl.org/). 20 ans plus tard, GIMP l’utilise pour ses traitements de pixel principaux et nous continuons à faire évoluer cette machinerie qui s’améliore au fil des jours. Divers autres logiciels utilisent désormais GEGL pour leurs propres traitements graphiques.



GIMP est aussi tellement complet qu’on améliore constamment l’écosystème autour de nous. Par exemple si on regarde mes contributions hors GIMP, on constate ainsi des [patchs dans des dizaines de *briques* importantes](https://www.openhub.net/accounts/Jehan/) du Logiciel Libre, et ce sans compter les centaines de rapports de bugs et aides au diagnostic de bug qui ont aussi abouti à des corrections ou améliorations. La même chose peut se vérifier d’autres développeurs de GIMP (comme notre mainteneur adoré, [Mitch](https://www.openhub.net/accounts/mitch)).



En outre GIMP est utilisé assez massivement dans les milieux universitaires, des équipes de recherche en traitement d’images notamment. Par exemple l’équipe CNRS du logiciel [G'MIC](https://gmic.eu/), avec laquelle j’ai travaillé en 2019, a initialement fait un plug-in pour GIMP, faisant de G'MIC une référence en collection de filtres. Je ne pense pas que David Tschumperlé qui lit aussi LinuxFr.org me contredira si je dis que GIMP a aidé à propulser G'MIC.
Nous avons régulièrement des retours d’autres universités qui ont utilisé GIMP dans des ateliers, des formations, parfois dans des projets de design logiciels, d’utilisabilité (plusieurs par le passé, notamment on se souvient de projet dans des universités belge et allemande au moins) ou de graphisme. Par exemple, ces dernières années, une université indienne (KBC North Maharashtra University) a travaillé sur la traduction complète de GIMP en [marathi](https://fr.wikipedia.org/wiki/Marathi_(langue)) et a organisé des ateliers et une formation autour de GIMP (apparemment certains cours autour de l’usage de GIMP, et d’autres cours sur la localisation logicielle avec des linguistes marathi). Et pour quelques-uns de ces projets dont on a vent, combien d’autres projets dont on a jamais entendu parler ?!
On a même eu parfois des retours de gens de la NASA qui nous disent utiliser GIMP !
Notre logiciel est donc une aide pour tous ces organismes publics ! 🥴

Dans les divers autres sujets trollifères autour de GIMP, notre mascotte de toujours, Wilber, fait aussi régulièrement parler d’elle. Nous rappelons alors aux gens que GIMP est communautaire, que nous aimons bien les personnages marrants et que cela n’est pas antithétique avec le travail de qualité, ni même professionnel. Non nous ne changerons pas pour une interface aseptisée pour faire bien dans les réunions entre *managers*! 🧑‍💼🤪



On appréciera aussi que GIMP co-crée en 2006 le [Libre Graphics Meeting](https://libregraphicsmeeting.org/) en extension de ses propres réunions de développeurs annuels pendant ces années-là. En effet les développeurs de l’époque se disent que le graphisme libre devrait rassembler les gens des divers projets et autour plutôt que créer des divisions. Depuis le projet GIMP a participé à chacune des réunions (Aryeom et moi-même n’en avons manqué personnellement aucune depuis 2013, lors de notre entrée dans l’équipe de GIMP), a même co-financé la réunion à de nombreuses reprises (notamment lors des périodes difficiles) et a aidé financièrement divers contributeurs d’autres projets à s’y rendre (notamment ces dernières années, de mémoire, des gens des équipes de MyPaint, darktable, Kdenlive, GTK…). Notre but est encore et toujours d’améliorer l’écosystème du libre dans sa globalité, notamment dans le graphisme et l’audiovisuel.


Toutes ces choses sont des anecdotes que j’apprécie particulièrement dans l’histoire de GIMP (même si je n’ai participé moi-même qu’à une portion de ces faits). J’aime ce côté communautaire et altruiste de GIMP. C’est pour moi exactement l’aspect qui m’attire et pour lequel je m’accroche au logiciel libre (pas tous les projets sont ainsi, loin de là). Ce projet nous a vraiment permis de découvrir un monde particulier duquel nous sommes heureux de faire partie. 💌



## Apports de ZeMarmot



Le projet [ZeMarmot](https://film.zemarmot.net/), que j’ai cofondé avec Aryeom, et qui fut rattaché à l’association [LILA](https://libreart.info/), eut bien sûr son impact puisque nous avons commencé à améliorer GIMP sur la base d’un usage réel au quotidien. Notamment, non seulement les fonctionnalités et une meilleure expérience de création nous motivait, mais aussi et toujours la stabilité du logiciel. Lorsque nous avons découvert GIMP en 2012 (on connaissait tous deux déjà de nom, mais pas “réellement”), je n’aurais pas pu conseiller à quelqu’un d’y passer professionnellement (je me rappelle encore de mes premières tentatives avec Aryeom, je pense qu’il nous a fallu 15 minutes pour faire marcher la tablette graphique et 5 minutes pour faire planter GIMP). De nos jours, après le travail accompli, on peut.



D’ailleurs en parallèle, nous avons aussi participé à quelques projets professionnels tiers, uniquement associatifs et pour des causes que nous apprécions (nous ne voulons pas travailler pour des grosses entreprises dont nous n’aimons pas l’impact sur le monde). Par exemple, nous avons fait 2 projets internes pour l’association des *Petits Frères des Pauvres* (un petit film institutionnel et un jeu de société pour la formation des bénévoles), nous avons aussi entièrement produit la vidéo ["What is Peertube?"](https://framatube.org/videos/watch/9c9de5e8-0a1e-484a-b099-e80766180a6d) pour Framasoft, vidéo toujours à ce jour la plus vue et “plussée” de l’instance [Peertube](https://joinpeertube.org/) de Framasoft, ce qui est assez méta ! D’autres associations nous ont contacté, notamment une association écologique, bien que nous essayons de limiter les projets secondaires pour nous focaliser sur *ZeMarmot* (mais ce n’est pas toujours évident de refuser tant que *ZeMarmot* n’est pas viable). Quand je dis *nous* pour beaucoup de ces projets, j’entends bien sûr surtout Aryeom (elle est alors celle qui fait le gros du travail !). Moi je fais le soutien technique !

En plus de cela, depuis maintenant 3 ans d’affilée, Aryeom donne des cours universitaires avec GIMP pour 2 classes de licences professionnelles (troisième année de licence), dans l’université de Cergy-Pontoise: une classe de retouche d’images pour la licence « Patrimoine et modélisation 3D » et une classe d’illustration numérique pour la licence “Infographie”. Le responsable de licence est très content, d’année en année, prouvant la place incontestable de GIMP dans le monde professionnel (sans compter que nous entendons régulièrement que d’autres universités, entreprises ou organismes publics dans le monde font un usage très courant de GIMP, comme je disais plus haut).


Tous les contacts professionnels nous ont toujours rappelé et ont été contents des résultats. Il nous semble évident que le logiciel libre en général, et GIMP en particulier, est utilisable dans le milieu professionnel et nous le prouvons au quotidien.



# Financer le développement de GIMP



Pour conclure, nous vous rappelons que vous pouvez [donner au projet et financer personnellement plusieurs développeurs GIMP](https://www.gimp.org/donating/) qui rendent tout cela possible. C’est aussi une façon de renvoyer l’ascenseur et accélérer le développement de GIMP si vous appréciez le projet. Cette page propose 3 manières de donner: le projet *[ZeMarmot](https://film.zemarmot.net/fr/donate)* (dont je parle dans le prochain paragraphe en détail), le financement de [Øyvind Kolås](https://www.patreon.com/pippin), le mainteneur de GEGL (notre moteur graphique) et la donation au projet (qui ne peut servir que pour du financement communautaire, donc pour des financements de déplacements aux réunions ou pour du matériel de bénévole typiquement). Seuls les financements d’Øyvind et de *ZeMarmot* permettent de rémunérer du développement pour GIMP à ce jour.



Pour parler en particulier du [financement du projet *ZeMarmot*](https://film.zemarmot.net/fr/donate) dont je fais partie ([Liberapay](https://liberapay.com/ZeMarmot/), [Patreon](https://www.patreon.com/zemarmot), [Tipeee](https://en.tipeee.com/zemarmot) ou [donations directes à l’association LILA](https://libreart.info/fr/donate)), nous sommes donc responsables d’une grande partie des évolutions de GIMP ces dernières années (je suis d’ailleurs le contributeur le plus actif sur les 2 dernières années, avec plus de 1000 *commits* rien qu’en 2019 et 2020, et rien qu’en comptant le dépôt principal de GIMP ; et ce sans compter non plus les très nombreux retours d’Aryeom qui font bouger les choses aussi d’une autre manière, moins visible et moins chiffrable). Or notre projet cherche encore et toujours une stabilité financière (surtout après cette année difficile et un licenciement pour raisons économiques de mon précédent emploi !). Cela nous oblige d’ailleurs régulièrement à accepter d’autres emplois (développement pour moi et/ou films ou projets graphiques tiers pour Aryeom, comme j’expliquais plus haut) qui repoussent le développement libre et le projet de film libre d’autant. Imaginez la vitesse à laquelle on pourrait faire avancer les choses, si on pouvait travailler sur GIMP et *ZeMarmot* à temps plein ?! 😻
C’est pourquoi **nous appelons encore à la participation au financement de notre projet ZeMarmot**. Mon petit pitch habituel est de considérer cela comme un investissement pour un meilleur monde logiciel (GIMP et logiciel libre !) et audiovisuel (des œuvres audiovisuelles libres !). Donc en espérant que ces raisons vous interpellent aussi… aiderez-vous *ZeMarmot* et GIMP en cette fin d’année 2020 ? 👍
[![Soutenez ZeMarmot et GIMP!](https://film.zemarmot.net/images/ZeMarmot468x60pourLinuxfr.jpg)](https://film.zemarmot.net/fr/donate?referent=linuxfr)


🥳 Sur cette conclusion, nous vous souhaitons un très bon noël, malgré la situation sanitaire particulière ainsi qu’une année 2021 meilleure que 2020 ! 🎉