URL: https://linuxfr.org/news/gimp-2-99-4-et-2-99-6-don-t-worry-be-h-api
Title: GIMP 2.99.4 et 2.99.6: don't worry, be h-API!
Authors: Jehan
 Matthieu, Ysabeau 🧶, Benoît Sibaud, yal, palm123 et orfenor
Date: 2021年05月05日T23:51:54+02:00
License: CC By-SA
Tags: don, flatpak et gimp
Score: 109
GIMP 2.99.6, dernière version en date de ce qui deviendra GIMP 3, vient de sortir avec quelques améliorations visibles, et d’autres moins manifestes et pourtant essentielles. En particulier beaucoup de changements concernent l'*API* (*Application Programming Interface* : Interface de programmation, pour les développeurs de greffons), laquelle évolue beaucoup depuis que nous travaillons sur le futur GIMP 3.
☣️ Attention: **les sorties GIMP 2.99 sont des versions de développement (donc instables). Elles contiennent des bugs connus, parfois même des plantages et dans tous les cas des fonctionnalités non finies. À utiliser à ses propres risques!** ☣️
Alors que nous avions évoqué la version 2.99.2 sur LinuxFr.org, aucun article pour GIMP 2.99.4 (sortie le 25 décembre 2020) n’a été publié ici, ce pourquoi cet article discutera les changements apportés dans GIMP 2.99.4 et 2.99.6 (sortie le 8 mai 2021).
⚠️ De nombreux greffons déjà portés pour GIMP 2.99.2 ou 2.99.4 nécessiteront des changements pour fonctionner à nouveau, et il y a des chances pour que l’interface de développement évolue encore jusqu’à ce que nous stabilisions l’API. Nous nous en excusons d’avance, même si cela est le prix à payer si on développe des plug-ins pour un logiciel en cours de développement. Néanmoins mieux vaut le faire maintenant que de se retrouver bloqués sur une mauvaise interface pour les années à venir (la stabilité de l’API étant assurée à partir de GIMP 3).
![Travail en cours (outils à disposition si vous voulez aider) par Aryeom, Creative Commons by-sa 4.0 - GIMP 2.99.6](https://www.gimp.org/news/2021/05/08/gimp-2-99-6-released/gimp-2.99.6-202105-work-in-progress-Wilber-and-co.jpg)
*Travail en cours (outils à disposition si vous voulez aider) par [Aryeom](https://film.zemarmot.net), Creative Commons by-sa 4.0 - GIMP 2.99.6*
----
[Annonce de sortie de GIMP 2.99.4](https://www.gimp.org/news/2020/12/25/gimp-2-99-4-released/)
[Annonce de sortie de GIMP 2.99.6](https://www.gimp.org/news/2021/05/08/gimp-2-99-6-released/)
[Dépêche sur LinuxFr pour GIMP 2.99.2](https://linuxfr.org/news/25-ans-de-gimp-et-version-de-developpement-2-99-2-premiers-pas-vers-gimp-3)
[Page de donation de GIMP](https://www.gimp.org/donating/)
[Projet ZeMarmot (co-maintenance de GIMP)](https://film.zemarmot.net/fr/)
----
# Nouveautés notables :
- amélioration d’utilisabilité de l’interface ;
- amélioration de l’outil Sélection par Peinture (expérimental) ;
- nouvelles interfaces de programmation de greffon pour la génération de boîtes de dialogues et la prise en charge de métadonnées ;
- guides hors canevas ;
- sélecteur de modèle dans la boîte de dialogue « Taille du canevas » ;
- prise en charge du geste de pincement sur le canevas pour zoomer ;
- meilleure gestion des chunks *gAMA* et/ou *cHRM* du PNG ;
- évolution de l’API ;
- documentation initiale pour le port de greffons à l’API 3.0.
# Améliorations notables
## Contrôle graphique "curseur" (2.99.4)
Nous avons corrigé plusieurs problèmes de découverte des fonctionnalités du nouveau *widget* [curseur compact](https://linuxfr.org/news/25-ans-de-gimp-et-version-de-developpement-2-99-2-premiers-pas-vers-gimp-3#toc-curseurs-compacts). Ceci est principalement le résultat de tests d’utilisabilité effectués par Aryeom et notamment incluant des tests réels d’usage en production.
Précédemment, si vous essayiez de changer la valeur du curseur numériquement (c’est-à-dire avec entrée clavier), un clic de souris dans la zone de texte provoquait aussi un saut de valeur. Il fallait cliquer avec le bouton milieu pour éviter cela, ce qui n’est pas vraiment un comportement « découvrable ».
À la place, vous pouvez maintenant viser précisément la zone de texte, ce qui ne provoque plus un changement de valeur mais passe en édition de texte (avec sélection de la valeur entière par défaut, comme il est d’usage dans les entrées de texte).
Le second problème venait des changements de pointeurs en fonction du contexte :
* Nous utilisions un pointeur « flèche vers le haut », reliquat d’une époque où ce *widget* avait deux zones d’action : une zone haute et une zone basse. Cela n’a plus de sens avec le nouveau mode d’interaction. Nous avons donc remplacé ce pointeur par un pointeur "*attraper*" (*grab*), tel que défini dans la spécification CSS et qui définit bien une action rapide et pas forcément précise. Ce pointeur se transforme alors en pointeur "*attrapé*" (*grabbing*) quand un clic-déplacer est en cours, lequel suit le pointeur.
* Quand le pointeur passe au-dessus de la zone texte, il devient alors un pointeur d’édition «*texte* » rendant plus évident qu’un clic dans cette zone permettra d’éditer la valeur directement au clavier.
* Enfin si vous maintenez enfoncée la touche modificatrice `Shift`, le pointeur devient un pointeur de redimensionnement horizontal ("*col-resize*" dans la spécification CSS), mettant ainsi en avant une capacité d’édition plus fine, relative aux mouvements du pointeur (action aussi disponible avec le troisième bouton, lequel correspond en général au clic droit d’une souris pour droitier).
![GIMP 2.99.4: from left to right, new cursors on the slider to grab, when grabbing, do small updates or text-edit](https://www.gimp.org/news/2020/12/25/gimp-2-99-4-released/gimp-2.99.4-slider-cursors.png)
*GIMP 2.99.4 : de gauche à droite: nouveaux curseurs pour « attraper » (édition absolue), lors d’un clic-déplacer, pour une édition fine (édition relative) et pour l’édition de texte*
## Amélioration d’utilisabilité de la sélection multi-calques (2.99.4)
Comme on le disait avec la sortie de GIMP 2.99.2, [la sélection de calques multiples](https://linuxfr.org/news/25-ans-de-gimp-et-version-de-developpement-2-99-2-premiers-pas-vers-gimp-3#toc-s%C3%A9lectionner-plusieurs-calques-%C3%A0-la-fois) dans la fenêtre ancrable `Calques` est désormais possible avec les modificateurs classiques de sélection multiple, à savoir `Shift-click` pour une sélection consécutive ou `Ctrl-click` pour la modification de sélection. Or ces modifications étaient en conflit avec des fonctionnalités existantes sur les aperçus de calques et de masques de calques. On pouvait alors se retrouver à créer ou supprimer des calques sans s’en rendre compte en sélectionnant de multiples calques.
![Sélection multiple de calques](https://pic.infini.fr/UKhXMd3t/0qocGsbf.gif) (NdM: image reprise de archive.org)
Puisque la fonctionnalité de sélection multiple est bien trop primordiale, et qu’en plus ces modificateurs sont bien établis dans l’usage informatique, il n’était pas logique de définir des modificateurs différents pour la sélection multiple. Nous avons donc fait les choix suivants :
* Les modificateurs `Shift`, `Ctrl` ou `Shift-Ctrl` ne peuvent être utilisés seuls pour la moindre fonctionnalité dans la fenêtre ancrable des calques (hors la sélection multiple).
* Toute interaction existante ne suivant pas cette règle a été changée pour utiliser une combinaison avec `Alt+` à la place.
* Lorsque toutes les combinaisons de modificateurs étaient déjà prises, nous avons retiré des fonctionnalités en fonction de leur ancienneté (par exemple _Alpha vers sélection_ existe depuis presque la naissance de GIMP alors que les raccourcis de création de masque sont récents, d’il y a à peine quelques années).
* Les raccourcis se basent sur des combinaisons exactes de modificateurs pour éviter les collisions (par exemple `Ctrl-clic` ne doit pas déclencher à la fois une fonctionnalité qui utilise `Ctrl-clic` et une autre en `clic` simple).
* Les raccourcis avec modificateurs sur les aperçus ne doivent pas changer la sélection de calque ou de masque, et en outre n’affectent plus que le calque ou masque cliqué, et non pas l’ensemble des calques/masque sélectionnés. Cela rend ces actions moins redondantes.
De manière concrète, les changements sont donc :
* `Ctrl-clic` sur un aperçu de masque pour (dés)activer le masque de calque devient `Alt-Ctrl-clic`. L’autre action de masque, `Alt-clic`, pour afficher le masque, ne change pas.
* Les actions `Shift-clic` et `Ctrl-clic` sur un aperçu de calque pour respectivement ajouter (avec les dernières valeurs utilisées) ou retirer un masque de calque ont été supprimées. En effet toutes les combinaisons de modificateurs `Alt+` sont prises (pour « *Alpha vers sélection* », « *Ajouter alpha à la sélection* », « *Soustraire alpha de la sélection* » et « *Intersection d’alpha avec la sélection* », respectivement en `Alt-clic`, `Alt-Shift-clic`, `Alt-Ctrl-clic` et `Alt-Shift-Ctrl-clic`; nous avons aussi utilisé cette opportunité pour améliorer les labels d’historique d’annulation de ces actions, ce qui améliore la découvrabilité de ces actions lors d’essais aléatoires) surtout que ces actions d’ajout/suppression de masque étaient de toutes façons très récentes (2.10.0).
* Les pop-up d’aperçus lors de clics longs ne se produisent plus lorsqu’un modificateur est pressé, retirant ainsi une distraction qui n’est évidemment pas l’objectif d’un tel clic.
Pour en savoir un peu plus sur les possibilités apportées par la sélection multiple de calques, telles que les possibilités d’organisation de calques (déplacement, suppression, duplication...) mais aussi de modification (transformations, découpe...) ou d’échantillonnage (de couleur composée, de canal alpha...), nous rappelons ce [rapport de développement](https://www.patreon.com/posts/report-on-for-in-37266151) assez précis, bien que non complet (puisque d’autres possibilités ou changements ont été amenés depuis).
## Boîte de dialogue des « Périphériques d’entrée » (2.99.4)
La terrible boîte de dialogue « Périphériques d’entrée » a toujours semblé encombrée d’options incompréhensibles. Pour GIMP 3, diverses fonctions devraient marcher sans configuration particulière, cela semblait l’opportunité d’un peu de nettoyage.
* Nous montrons maintenant seulement les entrées pour les périphériques attachés physiquement à votre ordinateur. En particulier, nous ne montrons plus les périphériques « virtuels ». De même, nous cachons aussi maintenant le périphérique `XTEST` généré par le serveur X11 (Linux).
* Nous montrions jusqu’à maintenant tous les axes d’entrée possibles pour chaque périphérique, notamment des axes tels que « *Rotation* » ou « *Slider* » qui sont relativement rares (présents sur certains stylets spécifiques du marché, pas si répandus, même chez les professionnels du graphisme). La boîte de dialogue ne liste plus que la liste d’axes retournée par le *backend* (notons que même cette liste peut montrer trop d’axes, car certains pilotes génériques ne sont pas suffisamment précis; cela reste néanmoins plus proche de la réalité du matériel).
* Quand un périphérique est connecté, le nom des axes est celui listé par le *backend*, permettant ainsi des noms plus proches de la réalité. Par exemple, l’axe `X` d’une tablette graphique s’afficherait souvent en `Abs. X` parce que ces périphériques sont habituellement faits pour du pointage absolu alors qu’une souris montrerait un axe `Rel.X`.
* L’édition de courbes de pression est l’une des options de configuration les plus utiles de cette interface, en particulier maintenant qu’il n’est même plus nécessaire d’activer ou désactiver des périphériques. C’est pourquoi lorsqu’un périphérique a un axe « Pression », celui-ci sera sélectionné par défaut pour aller plus vite à l’essentiel.
**Appel à retours** :
Cette boîte de dialogue a encore quelques configurations qui nous échappent ou dont nous ne sommes pas sûrs de l’usage ou l’utilité. C’est pourquoi nous prenons avec joie tout retour de quelqu’un qui les utilise. La chose que nous ne souhaitons pas faire est de retirer des fonctionnalités que nous croirions par erreur inutiles ou cassées (peut-être à une époque, ce n’était pas le cas, mais avec le temps et les changements de paradigmes, ça a pu devenir le cas), même s’il y a peu d’utilisateurs pour ladite fonctionnalité. Comment utilisez-vous donc les fonctionnalités suivantes ? Quel système d’exploitation ? Pourquoi ?
* La boîte de dialogue de « Périphériques d’entrée » affichait notamment une liste de « **Touches** » pour chaque périphérique listé. Dans GIMP 2.99.2 déjà, nous avons retiré cette liste. Sur la base de nos tests, recherche de code et nos discussions avec Carlos Garnacho, notre expert résident GTK et en périphériques d’entrée, nous avons conclu que ce concept de "Touches" est lié aux périphériques de type « clavier » (que nous ne listons pas dans cette boîte de dialogue) et qu’il n’a aucun sens pour les périphériques de type « pointeur » (souris, pavés tactiles, tablettes graphiques... lesquelles ont un concept de « Boutons »). Et pourtant l’option était là depuis tant d’années. Y a-t-il un usage caché que nous ne comprenons pas? Était-ce utile à une époque? Si quelqu’un en sait plus et surtout utilisait cette option pour quelque chose, nous accueillons les retours d’information pour discuter comment ramener la fonctionnalité avec une interface la rendant au moins compréhensible.
* La liste « Axes » a la possibilité de reconfigurer un « **usage d’axe** » (le petit numéro à droite de la liste des axes). Cependant on ne comprend pas vraiment ce que fait ce champ et il ne semble pas utile. Qui a déjà utilisé cette configuration ?
* Chaque périphérique a trois « modes » : Désactivé, Écran, et **Fenêtre**. « Désactivé » signifie simplement que le périphérique partagera le pointeur du périphérique virtuel principal alors que « Écran » le rend indépendant. Par contre le mode « Fenêtre » n’a de sens que pour les périphériques « flottants » (un concept vraisemblablement pas disponible sur toutes les plateformes) et cela semble cassé, du moins pour autant que nous ayons pu tester. Y a-t-il quelqu’un dans cet univers qui arrive à avoir un comportement différent et intéressant du pointeur en le mettant sur « Fenêtre » ?
Nous conseillons à quiconque a l’usage de ces fonctionnalités de rentrer en contact avec l’équipe de GIMP pour nous expliquer votre cas, car nous sommes autant dans l’incompréhension que nombre d’utilisateurs et nous demandons si cela fonctionne pour qui que ce soit. D’un certain côté, nous souhaitons donc retirer ces fonctionnalités vraisemblablement cassées depuis des années, de l’autre nous ne voulons pas le faire s’il existe en fait des cas pour lesquels elles fonctionnent. Au contraire, si de tels cas existent, nous voulons mieux les comprendre pour améliorer l’option et la rendre plus compréhensible (s’il y a des cas où l’option ne sert à rien, cela doit être visible plus clairement; si l’usage est très particulier, nous pourrions mieux l’expliquer pour que plus de monde en profitent; et même pour ceux qui utilisent déjà, nous pouvons probablement améliorer la simplicité d’usage). Si donc vous êtes un de ceux qui ont un tel usage, contactez-nous, par exemple en ouvrant un [rapport de bug](https://gitlab.gnome.org/GNOME/gimp/-/issues) pour nous en dire plus.
Enfin s’il existe d’autres types de configuration pour les périphériques d’entrée, que vous voulez voir ou faire améliorer dans cette boîte de dialogue, nous sommes preneurs de retour sur ces points également!
## Meilleures options par défaut pour les périphériques d’entrée (2.99.4)
Comme expliqué dans l’article sur [GIMP 2.99.2](https://linuxfr.org/news/25-ans-de-gimp-et-version-de-developpement-2-99-2-premiers-pas-vers-gimp-3#toc-prise-en-charge-am%C3%A9lior%C3%A9e-des-p%C3%A9riph%C3%A9riques-dentr%C3%A9e), GIMP 3 aura une bien meilleure prise en charge des périphériques d’entrée, notamment pour la détection et le branchement à chaud. Nous avons donc décidé d’améliorer les paramètres par défaut lorsqu’un périphérique est détecté pour la première fois. L’objectif est de proposer un meilleur comportement initial, en particulier pour les tablettes graphiques où on s’attend en général à avoir une gestion appropriée de la pression.
Ainsi voici les outils sélectionnés la première fois en fonction du type de périphérique :
* Stylet (périphérique d’entrée principale pour une tablette) : outil *Pinceau* ;
* Gomme (périphérique d’entrée à l’arrière des stylets de tablette) : outil *Gomme* ;
* Tactile (doigt) : outil de *barbouillage* ;
* Autres périphériques : outil *Pinceau*.
En outre la dynamique par défaut de tout nouveau périphérique est maintenant « *Pression Taille* », c’est-à-dire une taille de brosse qui grandit lorsque la pression sur le stylet augmente.
Nous nous attendons à ce que cela améliore le premier usage de GIMP pour les utilisateurs de tablettes qui pourront alors peindre directement sur le canevas sans devoir comprendre au préalable toute la logique technique du système de peinture de GIMP (basé sur la combinaison de brosses et de dynamiques).
## Aperçus de polices de caractère adaptés pour le Coréen et le Japonais (2.99.4)
Notre liste de polices de caractère peut maintenant mettre en avant les polices ciblants les systèmes d’écriture coréen et japonais, en affichant respectivement « 한 » ou « あ ». Cela permettra donc de détecter bien plus rapidement les polices utiles pour son langage de prédilection, surtout si la liste est longue.
![Aperçu de polices dans divers script - GIMP 2.99.4](https://www.gimp.org/news/2020/12/25/gimp-2-99-4-released/gimp-2.99.4-fonts-CJK.png)
*Aperçu de polices dans divers scripts - GIMP 2.99.4*
Pour le coréen, « 한 » (han) fut choisi (outre d’être la première syllabe d« Hangeul », le nom du système d’écriture coréen) tout d’abord, car il s’agit d’une syllabe à double-consonne, ce qui peut donner une bonne idée des choix stylistique d’une police, ensuite, car la forme circulaire du « ᄒ » (hieut) ainsi que son petit *chapeau* font l’objet de nombreuses variantes stylistiques par les designers de polices de caractère. Cette syllabe est donc un caractère qui donne souvent de bons indices en un coup d’œil sur les choix de design d’une police.
De son côté « あ » est le premier *kana* du syllabaire hiragana, qui est un des composants principaux du système d’écriture japonais.
La logique du code est basée sur l’approximation du langage cible d’une police en fonction des caractères pris en charge. Néanmoins cet algorithme n’est pas parfait, en particulier lorsqu’une police est créée dans le but de prendre en charge beaucoup de scripts et de langages différents. Cela reste tout de même une approximation utile globalement. Notons que l’algorithme d’approximation du langage cible existait déjà et fonctionnait pour d’autres systèmes d’écriture, mais pas encore pour mettre en avant des polices ciblant le coréen et le japonais.
## Nouvel outil de sélection par peinture (2.99.4 et 2.99.6)
Thomas Manni, contributeur au long cours, travaille sur un nouvel outil de sélection avec une interaction de type « peinture » depuis GIMP 2.99.4. Cet outil propose une nouvelle manière de sélectionner des formes en peignant grossièrement la zone d’intérêt.
L’outil repose sur un algorithme de segmentation ciblée (graphcut) : son but est d’isoler rapidement une région spécifique de l’image. La sélection résultante est binaire (sélection complète ou nulle d’un pixel ; pas de sélection partielle).
Dans GIMP 2.99.6, cet outil reste considéré « expérimental » tant que son contributeur, ne le considère pas stable. Ceci dit l’outil a été amélioré considérablement et devient de plus en plus intéressant.
Plusieurs bogues ont été corrigés et la sélection est maintenant limitée au *viewport* (la partie visible du canevas) ce qui rend la sélection bien plus rapide en fonction du zoom.
Néanmoins l’outil reste encore à un stade intermédiaire de développement et il peut être imprécis et lent dans beaucoup de cas. Une optimisation de l’algorithme est prévue par le contributeur pour rendre l’outil vraiment rapide, mais cette étape se fera ultérieurement, une fois que l’étape purement fonctionnelle sera terminée. À suivre !...
Ce travail s’est produit aussi bien dans la base de code de GIMP que dans celle de son moteur graphique, GEGL.
![Copy-pasting Wilber in a few seconds with the Paint Select tool (realtime GIF) - GIMP 2.99.6](https://www.gimp.org/news/2021/05/08/gimp-2-99-6-released/gimp-2.99.6-paint-select-tool-test.gif)
*Copier-coller Wilber en quelques secondes avec l’outil de sélection par peinture (GIF en temps réel, rapide grâce au zoom sur le personnage) - GIMP 2.99.6*
En aparté, l’outil de sélection par peinture a ses propres icônes depuis GIMP 2.99.6, d’un design original de Yash Arya, avec le travail et design collaboratif pour revue et finalisation d’Aryeom.
![New Paint Select tool icon by Yash Arya and Aryeom - GIMP 2.99.6](https://www.gimp.org/news/2021/05/08/gimp-2-99-6-released/gimp-2.99.6-icon-tool-paint-select.png)
### Qu’en est-il de l’outil d’extraction du premier plan ?
On peut se demander ce qu’il adviendra de l’outil d’extraction du premier plan dont l’usage semble vraiment similaire. Cette citation de Thomas Manni explique la différence :> Foreground Select uses a matting algorithm: its goal is to provide an alpha (grey) value for all "unknown" pixels. Generally it should be used only on regions where pixels’ colors are a mix of foreground and background colors (like strands of hair or fur).
Qui peut être traduite ainsi :> L’extraction de premier plan utilise un algorithme de *matting*: son but est de fournir une valeur alpha pour tous les pixels « inconnus ». On utilise cela généralement sur des régions où les pixels de couleurs sont un mélange d’avant et d’arrière-plan (comme les cheveux ou de la fourrure).
Ces nouveaux développements viennent en partie de notre frustration avec cet outil historique qui ne marche pas si bien lorsque l’on souhaite segmenter des formes plus globales, prend souvent beaucoup de temps et de mémoire, sans compter des problèmes de stabilité. Néanmoins nous ne prévoyons pas de remplacer l’outil d’extraction du premier plan pour autant, mais d’offrir de nouveaux moyens de sélection. Par contre, il est possible que nous travaillions ensuite à améliorer le mode d’interaction avec l’outil d’extraction du premier plan et possiblement en re-ciblant son usage. Peut-être en faire un outil pour finaliser les bords ou détails de sélections existantes par exemple pourrait le rendre bien plus utile. Bien sûr, tout cela reste théorique à ce stade et davantage d’expérimentations et de développement seront nécessaires avant d’en arriver là.
## Guides hors canevas (2.99.6)
Dans la continuation des nouvelles possibilités de [visibilité hors canevas](https://linuxfr.org/news/gimp-2-10-14-et-2-10-18-sans-limites#toc-la-vue-et-l%C3%A9dition-horscanevas), les guides peuvent maintenant être eux aussi positionnés hors des limites du canevas. Cela est utile pour les divers cas d’usage où on souhaite travailler sur des images plus grandes que leur canevas.
Pour quiconque qui s’inquiéterait des règles d’interactions avec les guides, notamment pour les supprimer en les déplaçant hors du canevas, cela a simplement été changé en déplacement hors de la fenêtre. Après tests intensifs de ce changement pendant quelques mois (et après avoir reçu divers retours d’autres testeurs), nous avons estimé que cela ne changeait pas tellement l’usage au final.
![Guides hors canevas - GIMP 2.99.6](https://www.gimp.org/news/2021/05/08/gimp-2-99-6-released/gimp-2.99.6-off-canvas-guides.png)
## Sélecteur de modèles dans l’interface de « Taille du canevas » (2.99.6)
Un usage commun est de vouloir redimensionner son canevas dans un format standard, par exemple les formats de papier. C’est pourquoi le nouveau — et déjà prolifique — contributeur Stanislav Grinkov a implémenté un sélecteur de modèles dans la boîte de dialogue « Taille du canevas ».
![Sélecteur de modèle dans la boîte de dialogue « Taille du canevas » - GIMP 2.99.6](https://www.gimp.org/news/2021/05/08/gimp-2-99-6-released/gimp-2.99.6-template-selector-canvas-size.png)
Afin de prendre en compte les cas où la résolution spatiale (densité de pixels par unité de longueur physique) enregistrée pour un modèle est différente de celle de l’image en cours, la boîte de dialogue peut vous demander de décider si vous souhaitez changer la résolution spatiale de l’image ou au contraire mettre à l’échelle le modèle pour garder les dimensions physiques de ce dernier.
## Geste de pincement sur canevas pour zoomer (2.99.6)
Une nouvelle assez récente, car le code (de Povilas Kanapickas, nouveau contributeur) fut inclus quelques jours avant la sortie : GIMP reconnaît donc un geste de pincement avec les doigts sur un pavé tactile (par exemple sur un ordinateur portable, voir cette [courte vidéo](https://download.gimp.org/pub/gimp/video/v2.99/gimp-2-99-6-zoom-gesture.mp4)), ainsi que certaines tablettes graphiques ou écrans tactiles (cela peut ne pas fonctionner sur tous les modèles). En d’autres termes, si vous avez un périphérique tactile, on peut désormais zoomer en avant ou en arrière avec des mouvements digitaux (*note de l’auteur : on parle bien de mouvements de doigts ! Vrai sens de « digital »...* 😉).
Cela a été testé avec succès sur Linux/Wayland (sur un ordinateur portable avec pavé tactile et avec une tablette Wacom Intuos Pro) et cela pourrait fonctionner dans quelques mois sur X11 (quand [ce patch](https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/530) sera inclus). Quelqu’un a aussi déjà rapporté que cela fonctionnait sur Windows 10, avec un pavé tactile et un écran tactile d’ordinateur portable. À ce jour, personne ne nous a encore fait de retour pour macOS (la fonctionnalité dépend d’une fonction générique de GTK, mais la prise en charge exacte dépend d’implémentations spécifiques par plateforme ; en outre le *firmware* et/ou l’implémentation du pilote peuvent aussi changer le fonctionnement). L’étendue de cette prise en charge est donc encore inconnue, voire une surprise, pour l’équipe de GIMP. Nous acceptons les retours d’utilisations [sur le rapport associé](https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/401).
En note d’intérêt, on disait à un moment que la [prise en charge des mouvements digitaux](https://linuxfr.org/news/25-ans-de-gimp-et-version-de-developpement-2-99-2-premiers-pas-vers-gimp-3#toc-prise-en-charge-am%C3%A9lior%C3%A9e-des-p%C3%A9riph%C3%A9riques-dentr%C3%A9e) n’était pas notre priorité, et par ce fait risquait de ne pas être présente dans GIMP 3. Et pourtant en voici une première implémentation ! C’est encore un bel exemple du développement communautaire de GIMP, fait par tous et pas par une élite logicielle. Tout ce qui importe, si vous souhaitez voir la fonctionnalité de vos rêves dans GIMP, est que quelqu’un contribue à son implémentation... peut-être vous ?! 🙂
# Greffons
## Greffons de fichiers mis à jour avec interface graphique automatique (2.99.4)
Pour l’instant, 4 plug-ins ont bénéficié de la nouvelle interface de génération d’interface graphique générique pour les greffons (voir plus bas la section « [Génération d’interface graphique pour les greffons](#toc-génération-dinterface-graphique-pour-les-greffons-2994-et-2996) ») : les greffons PNG, JPEG, TIFF et FLI. Dans le cas le plus extrême, le code du plug-in JPEG a ainsi diminué de 600 lignes de code !
![PNG export dialog fully generated in a few lines of code: you don’t see much difference? That’s the point!](https://www.gimp.org/news/2020/12/25/gimp-2-99-4-released/gimp-2.99.4-png-export.png)
*Boîte de dialogue pour l’export en PNG entièrement générée à partir de quelques lignes de code. Vous ne voyez pas la différence ? C’est le but !*
## Préférences de fils d’exécution (*multi-threading*) accessibles aux greffons (2.99.4)
La boîte de dialogue _Préférences_ propose une configuration du « *Nombre de fils d’exécution à utiliser* » permettant un paramétrage selon son usage (par défaut, la valeur est configurée au nombre de *threads* détectés). Ce paramétrage n’était utilisé que par les traitements centraux de GIMP (les effets GEGL en particulier). Il est maintenant mis à disposition en lecture aux greffons avec la fonction `gimp_get_num_processors()`, permettant aux greffons de suivre aussi les préférences des utilisateurs plutôt que de prendre des décisions aléatoires.
Le greffon HEIF/AVIF utilise maintenant cette fonction (il était déjà *multi-threadé*, mais utilisait justement le nombre de *threads* du système sans possibilité d’outrepasser ce paramétrage - or ce type de paramétrage est typiquement un cas où de nombreux avis et besoins peuvent exister). Le greffon d’import d’image JPEG2000 quant à lui ne faisait pas de traitement parallèle et a maintenant été mis à jour pour décoder les images sur autant de fils d’exécution que paramétré, donc plus rapidement.
## Diagnostic amélioré des greffons (2.99.4)
Lloyd Konneker a amélioré l’infrastructure de *debug* des greffons. Notamment l’aide intégrée au *debug* des greffons fait maintenant la différence entre erreurs `WARNING` et `CRITICAL` pour des corrections mieux ciblées.
## PNG: profil de couleur généré lors de l’import de métadonnées gAMA et cHRM (2.99.6)
Le format PNG a plusieurs manières de gérer les couleurs, l’une d’elles étant par les profils de couleurs, ce qui est aussi la logique dans GIMP, comme dans tout éditeur graphique moderne. Dans la spécification PNG, la présence d’un profil de couleurs est considéré prioritaire et outrepasse toutes les autres méthodes de gestion des couleurs.
Les autres méthodes sont basées sur l’usage de métadonnées PNG: `gAMA`, `cHRM` et `sRGB`. Ainsi à la place d’un profil complet, un fichier PNG peut contenir la correction gamma dans une valeur unique (ce qui signifie notamment que la courbe gamma assez complexe de sRGB ne peut être représentée exactement de cette façon-là, mais une approximation est possible) dans la métadonnée `gAMA` de même que les chromaticités primaires peuvent être enregistrées dans la métadonnée `cHRM`.
L’implémentation de GIMP n’a jamais pris en charge cette méthode dépréciée de gestion de couleur basée sur une valeur gamma unique (et ne le fera jamais, car il s’agit d’une logique simpliste et ancienne qui ne doit pas être implémentée comme logique centrale dans du code nouveau). Néanmoins nous voulions pouvoir lire et afficher correctement les images utilisant ces métadonnées. Notre contournement historique était d’enregistrer les métadonnées `gAMA` et `cHRM` dans un `parasite` sur le fichier XCF puis de simplement l’enregistrer à nouveau dans le fichier PNG d’export (si on réexporte aussi en PNG). Cela signifie donc que les couleurs de l’image sont affichées incorrectement dans GIMP mais sont correctes après exportation.
Ce que GIMP va maintenant faire est de créer un profil de couleur ICC généré à partir des valeurs simplistes `gAMA` et `cHRM`. L’image sera donc maintenant affichée correctement. Puisque nous ne gardons plus ces métadonnées spécifiques PNG, il n’est plus nécessaire non plus de les ré-exporter, ce pourquoi l’option « *Save gamma* » (« Enregistrer le gamma ») a été retirée de la boîte de dialogue d’exportation PNG. Seuls les profils de couleur restent pris en charge (ainsi une image PNG « à l’ancienne » avec les métadonnées gAMA/cHRM importée par GIMP puis simplement ré-exportée sortirait avec un profile de couleur ICC équivalent). Notons que cela est recommandé par la spécification PNG [d’exporter avec un profil de couleur ICC quand un encodeur prend cela en charge](http://www.libpng.org/pub/png/spec/1.2/PNG-Encoders.html#E.Encoder-color-handling).
![Generating a color profile from PNG gAMA and cHRM chunks - GIMP 2.99.6](https://www.gimp.org/news/2021/05/08/gimp-2-99-6-released/gimp-2.99.6-color-profile-from-png-chunks.png)
## Plus de travail sur les greffons
* Notre greffon de capture d’écran présente plusieurs implémentations, et jusqu’à présent il créait systématiquement une boîte de dialogue. De nos jours, avec l’existence des portails sous Linux (par exemple sous Wayland ou avec les paquets logiciels type bac à sable), une plus grande partie du travail est déléguée au portail lui-même. C’est en particulier le cas du portail Freedesktop, qui demande quelle partie de l’écran doit être capturée et de quelle manière. Par conséquent, lorsque GIMP utilise le portail Freedesktop, il n’affichera plus notre boîte de dialogue désormais redondante.
* Les profils de couleur et les commentaires sont maintenant enregistrés pour chaque calque dans les fichiers TIFF afin d’éviter toute ambiguité lorsque ces fichiers sont lus par d’autres programmes (chaque calque peut en effet être muni de ses propres profil et commentaire en TIFF). Comme d’habitude, même si GIMP essaie d’être indulgent concernant les erreurs lors du chargement de fichiers (ce qui permet le sauvetage de fichiers endommagés), il doit être rigoureux lorsqu’il exporte un fichier lui-même.
* D’autres greffons ont reçus des améliorations mineures, comme l’indication de progression lors d’un export au format PDF, le support de la sélection multi-calque au format PSD, le portage de Qbist vers la nouvelle API...
# Évolution de l’API
## Génération d’interface graphique pour les greffons (2.99.4 et 2.99.6)
Nous avons travaillé sur la génération de boîtes de dialogue pour les greffons. Historiquement, un greffon est muni d’une « procédure » qui peut être appelée depuis le noyau de GIMP lui-même ou depuis d’autres greffons via le protocole `PDB`. Une procédure est appelée avec des paramètres et avec une méthode d’exécution choisie parmi trois possibles : interactive, non-interactive ou « avec les dernières valeurs utilisées ». Les paramètres sont définis par l’entité appelante pour une exécution non-interactive ou par l’appel précédent pour une exécution « avec les dernières valeurs utilisées », mais une exécution interactive nécessite de demander à l’utilisateur d’entrer les paramètres via une interface graphique, souvent avec des contraintes supplémentaires.
Jusqu’à présent, cela demandait toujours de coder des interfaces graphiques spécifiques. De nouvelles fonctions sont maintenant disponibles pour générer facilement les boîtes de dialogue à partir des paramètres de procédures. Dans les cas le plus simple, une boîte de dialogue complète peut être générée en moins de cinq lignes de code.
Plusieurs mécanismes de vérification ont été ajoutés, comme la validation des mnémoniques (les caractères soulignés dans les entrées des menus, utilisés pour faciliter la navigation au clavier). Cela garantit que chaque propriété affichée dans la boîte de dialogue d’un greffon possède un mnémonique unique. Cette fonctionnalité est très utile pour l’utilisabilité et l’accessibilité pour les personnes qui naviguent principalement à l’aide du clavier.
Une fonctionnalité similaire était disponible pour des _bindings_ spécifiques vers Python et Scheme jusqu’à la série 2.10 de GIMP. Contrairement à cette ancienne fonctionnalité, les nouvelles fonctions seront génériques, donc disponibles pour tous les greffons (greffons C/C++ mais aussi les *binding* généré par `GObject-Introspection`, par exemple en Python 3, JavaScript, Vala ou Lua). De plus, la personnalisation offerte est bien plus puissante et fournira des boîtes de dialogue améliorées et des comportements avancés.
## Nouvelle API générique pour le support des métadonnées (2.99.4)
Au cours du travail sur les boîtes de dialogue pour les greffons, nous avons aussi ajouté des fonctionnalités spécifiques aux greffons dédiés à l’export. En particulier, nous avons retravaillé la logique derrière les métadonnées et analysé les points communs entre les différents formats de fichiers.
Cela accompagne un travail plus en profondeur de Jacob Boerema sur la manipulation des métadonnées, en cours. Une partie de ce travail sera incorporée dans la série 2.10.x de GIMP, mais la partie la plus fondamentale sera peut-être disponible seulement à partir de GIMP 3.
## Davantage d’évolutions de l’*API*
* L’argument par défaut de la procédure d’un greffon était habituellement une seule image et un seul objet graphique (en général un calque). Depuis la version 2.99.6, GIMP fournit au greffon une image et un tableau d’objets graphiques, puisque GIMP peut dorénavant gérer la sélection multi-calques. Cela est la principale raison pour laquelle la plupart des greffons qui marchaient sur les précédentes versions 2.99.x ne fonctionneront plus. Nous en sommes désolés, mais cela est un mal nécessaire et est lié aux nouvelles capacités de GIMP pour une meilleure gestion des images complexes !
* Des efforts sont aussi en cours depuis GIMP 2.99.6 sur le concept de « sensibilité » de procédure de greffon, c’est-à-dire : quand le greffon est-il utilisable ? Jusqu’à la série 2.10.x de GIMP (et même dans les premières versions de développement 2.99.2 et 2.99.4), les greffons étaient sensibles à une image ouverte avec un seul objet graphique sélectionné. À présent, avec les capacités de sélection multiple, il se peut que vous vouliez un greffon qui marche aussi sur plusieurs calques à la fois, ou peut-être même **seulement** quand plusieurs calques sont sélectionnés ! Et si vous vouliez un greffon qui n’a pas même pas besoin d’avoir une image ouverte ? Du coup, nous avons ajouté une nouvelle fonction pour définir la sensibilité d’un greffon, et nous réfléchissons même déjà à pousser cela encore plus loin (c’est pourquoi nous ne mentionnons pas le nom de la fonction ici et nous vous déconseillons de l’utiliser pour le moment si vous la trouvez, car elle va probablement changer).
* De plus, de nombreuses fonctions ont été renommées pour plus de cohérence et parfois aussi pour éviter les collisions de noms lors de la génération des _bindings_, comme `gimp_parasite_name()` qui est devenue `gimp_parasite_get_name()`. Voici la [liste des noms de fonctions mis à jour](https://gitlab.gnome.org/GNOME/gimp/-/blob/419892c3bd50dac7c671ac719cd6a9c5997691f5/NEWS#L97) dans GIMP 2.99.6.
* Les « parasites » (le nom technique pour les données quelconques attachées à une image, un calque ou à GIMP lui-même) peuvent maintenant être passés en tant qu’arguments à une procédure. Ce changement peut sembler étrange, mais cela est utile quand vous voulez enregistrer des données quelconques (même binaires) d’une session GIMP à l’autre. Cette astuce est déjà utilisée dans le greffon QBist (parmi les greffons par défaut).
Beaucoup d’autres changements ont été apportés à l’API, et vous pourrez avoir une vue d’ensemble peut-être meilleure en lisant le fichier [NEWS](https://gitlab.gnome.org/GNOME/gimp/-/blob/419892c3bd50dac7c671ac719cd6a9c5997691f5/NEWS#L50), même si ce fichier n’est pas forcément exhaustif (nous pouvons avoir oublié de noter certains changements !).
## Documentation
Nous avons commencé un embryon de [documentation pour le portage des greffons](https://gitlab.gnome.org/GNOME/gimp/-/blob/master/devel-docs/GIMP3-plug-in-porting-guide/) vers l’interface 3.0. Nous accueillons à bras grands ouverts quiconque suit les changements d'*API* et souhaite aider à écrire la documentation (regarder les changements effectués sur les greffons portés dans GIMP serait un bon début). L’interface est encore mouvante mais la logique centrale est déjà plutôt stable donc des écrivains techniques peuvent déjà commencer l’écriture de la logique fondamentale.
# Nouvelle traduction de l’installeur Windows (2.99.6)
Notre installateur Windows bénéficie d’une nouvelle [traduction en hébreu](https://l10n.gnome.org/languages/he/gnome-gimp/ui/) (GIMP lui-même avait déjà une traduction partielle en hébreu).
Comme d’habitude, profitons-en pour remercier l’ensemble de nos traducteurs qui font aussi un travail d’exception !
En parlant de traducteurs, je voudrais aussi remercier celles et ceux de LinuxFr.org qui m’aident à chaque fois à ré-écrire ces dépêches en français. Même en ayant écrit une majeure partie en anglais, cela reste un gros travail de tout réécrire. Donc merci à vous, rédacteurs de dépêche communautaire ! 🙏
# GEGL et babl
Puisque nous avons sorti une [version stable il y a peu](https://linuxfr.org/news/gimp-2-10-24-version-cartographe), GIMP 2.99.6 a les mêmes dépendances : [babl](https://gegl.org/babl/) 0.1.86 et [GEGL](https://gegl.org/) 0.4.30. Ces bibliothèques devenant plus stables avec le temps, moins de sorties sont nécessaires.
Les versions précédentes, babl 0.1.84 et GEGL 0.4.28 qui accompagnèrent GIMP 2.99.4 apportèrent toutefois deux opérations d’intérêt :
- `gegl:paint-select` qui est là où se trouve tout le traitement réel pour le nouvel outil de sélection par peinture, par Thomas Manni
- `gegl:icc-load` pour traiter les fichiers `.icc` comme des images, permettant ainsi de charger l’espace de couleur directement depuis un fichier de profil afin de l’utiliser dans le graphe de traitement d’image.
Øyvind Kolås passe beaucoup de temps désormais à l’amélioration de son dernier project [ctx](https://pippin.gimp.org/ctx/) (un émulateur de terminal/bibliothèque/protocole/plateforme d’imagerie vecteur 2D dont nous avions [déjà parlé](https://www.gimp.org/news/2020/01/04/gimp-and-gegl-in-2019/#whats-new-in-gegl-and-babl) il y a un an).
# Télécharger GIMP 2.99.6
Comme les versions précédentes, GIMP 2.99.6 est mis à disposition sur le [site officiel de (gimp.org)](https://www.gimp.org/downloads/devel/):
* Le paquet flatpak pour Linux est comme d’habitude disponible à peine quelques heures après le *tag* des sources. Votre logiciel de gestion de logiciels devrait vous proposer une mise-à-jour s’il était déjà installé (alternativement en ligne de commande: `flatpak update org.gimp.GIMP`).
* L’installateur Windows est aussi disponible.
*Note : nous nous sommes rendu compte que quelques changements listés dans cet article n’ont pas été intégrés dans le dernier installateur de GIMP 2.99.6 (telle que la traduction en hébreu de l’installateur lui-même ainsi que l’outil de sélection par peinture à cause d’options de compilation ou dépendances manquantes). Nous corrigerons cela dans un installateur à venir !*
* Il n’y a encore eu de paquet macOS pour aucune version de développement 2.99.x. Comme d’habitude, nous rappelons que cela dépend du temps et de la volonté des contributeurs, et surtout que notre équipe est constituée entièrement de volontaires. Si vous veulez aider pour améliorer notre réactivité à la prise en charge de macOS, nous vous accueillons les bras grands ouverts ! 🤗
Nous souhaitons d’ailleurs remercier également tous les empaqueteurs de GIMP, passés, présents et futurs. Sans eux, GIMP serait bien moins simple à installer ! Leur contribution est ainsi extrêmement précieuse à la communauté.
# Bonus: BD de Noël
Un peu en retard, mais puisque GIMP 2.99.4 a été annoncé le 25 décembre 2020, la sortie a été accompagnée d’une BD de Noël, comme d’habitude dessinée et écrite par [Aryeom](https://film.zemarmot.net/) sous licence Creative Commons by-sa 4.0. La voici, juste pour le plaisir !
[![GIMP 2.99.4 present for Christmas! by Aryeom, Creative Commons by-sa 4.0](https://www.gimp.org/news/2020/12/25/gimp-2-99-4-released/2020-gimp-2-99-4-xmas.jpg)](https://www.gimp.org/news/2020/12/25/gimp-2-99-4-released/2020-gimp-2-99-4-xmas.jpg)
# Et ensuite ?
Dernièrement, comme vous avez pu le constater, une grande partie de notre attention a été portée vers l’interface applicative (`libgimp`), que nous peaufinons toujours pour fournir la meilleure interface possible avec les greffons en nous basant sur [25 années](https://www.gimp.org/news/2020/11/21/25-years-of-gimp/) d’expérience partagée avec la communauté. Même si cet aspect n’est pas très visible, il est important, car nous assurons la stabilité des versions majeures de l’API. Autrement dit, les changements d’API après la sortie de GIMP 3.0 ne peuvent être qu’incrémentaux, petits bouts par petits bouts. C’est notre seule chance pour améliorer les choses en profondeur (en faisant de notre mieux, il y aura des erreurs bien sûr, mais essayons de les limiter autant que possible).
Même pour les non-développeurs, une bonne API signifie que vous pourrez installer des greffons nombreux et utiles dans le futur.
Du côté de GTK3, le portage de `GtkAction` est toujours le plus gros point restant. Des problèmes sérieux avec Wayland doivent encore être examinés. De son côté, l’_invasion venue de l’espace_ (nom de code du projet) continue, et ainsi de suite. Même si des progrès ont été faits sur la plupart des sujets, le [rapport de développement](https://www.patreon.com/posts/what-remains-to-40087754) que nous avons partagé il y a quelques mois est encore assez à jour.
Comme d’habitude, nous ne donnons aucune date précise de sortie pour GIMP 3.0. Nous ne la connaissons pas nous-mêmes, et de plus cela dépend de temps offert bénévolement par les contributeurs. Nous sommes très heureux d’avoir accueilli de nouveaux contributeurs talentueux au cours des derniers mois (et nous espérons qu’ils resteront avec nous longtemps). Nous serions aussi très heureux d’en accueillir davantage, donc si quelqu’un veut participer, vous êtes les bienvenus pour vous joindre à nous !
Pour finir, n’oubliez pas que vous pouvez [faire un don au projet et financer personnellement plusieurs développeurs de GIMP](https://www.gimp.org/donating/), ce qui est une manière de donner en retour et d’accélérer le développement de GIMP. En effet, en tant que projet communautaire, GIMP progresse grâce aux contributeurs qui font don de leur temps. **C’est pourquoi nous avons récemment mis à jour la page des dons pour insister sur l’importance de donner aux développeurs le souhaitant pour assurer la pérennité du projet.**
On notera que cela inclut la mise en avant de [Øyvind Kolås](https://www.patreon.com/pippin) (mainteneur de notre moteur graphique GEGL), ainsi que du projet [ZeMarmot](https://film.zemarmot.net/fr/donate) dont Aryeom (dont vous pouvez voir diverses œuvres libres sur cet article, sur [gimp.org](https://www.gimp.org/) et ailleurs) et moi-même faisons partie et grâce auquel on a été capable de contribuer massivement à GIMP (~30% des commits sur les 2 dernières années, sans compter les retours et tests d’utilisation réels, les designs de fonctionnalité, revue de code, etc.). On espère donc pouvoir continuer ainsi, grâce à tous les donateurs que l’on remercie chaleureusement 💌, ce pourquoi on se finance sur [Liberapay](https://liberapay.com/ZeMarmot/), [Patreon](https://www.patreon.com/zemarmot), [Tipeee](https://en.tipeee.com/zemarmot)...
Sur ces paroles pleines d’espoir pour ce logiciel libre et communautaire, nous vous souhaitons à tous tout plein de belle créativité avec GIMP ! 💞
</div><div class="naked_ctrl">
<form action="/index.cgi/contrast" method="get" name="gate">
<p><a href="http://altstyle.alfasado.net">AltStyle</a> によって変換されたページ <a href="httpS://linuxfr.org/news/gimp-2-99-4-et-2-99-6-don-t-worry-be-h-api.md">(-&gt;オリジナル)</a>
/ <label>アドレス: <input type="text" name="naked_post_url" value="httpS://linuxfr.org/news/gimp-2-99-4-et-2-99-6-don-t-worry-be-h-api.md" size="22" /></label> <label>モード: <select name="naked_post_mode">
<option value="default">デフォルト</option>
<option value="speech">音声ブラウザ</option>
<option value="ruby">ルビ付き</option>
<option value="contrast" selected="selected">配色反転</option>
<option value="larger-text">文字拡大</option>
<option value="mobile">モバイル</option>
</select>
<input type="submit" value="表示" />
</p>
</form>
</div>