Sommaire
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. 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 : 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 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.
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 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 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, 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 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.
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.
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, 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.
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 ».
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), 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 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é.
En note d’intérêt, on disait à un moment que la prise en charge des mouvements digitaux 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 ») : 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 !
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.
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 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, 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 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 (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, GIMP 2.99.6 a les mêmes dépendances : babl 0.1.86 et GEGL 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 (un émulateur de terminal/bibliothèque/protocole/plateforme d’imagerie vecteur 2D dont nous avions déjà parlé 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):
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 sous licence Creative Commons by-sa 4.0. La voici, juste pour le plaisir !
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 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 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, 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 (mainteneur de notre moteur graphique GEGL), ainsi que du projet ZeMarmot dont Aryeom (dont vous pouvez voir diverses œuvres libres sur cet article, sur 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, Patreon, Tipeee…
Sur ces paroles pleines d’espoir pour ce logiciel libre et communautaire, nous vous souhaitons à tous tout plein de belle créativité avec GIMP ! 💞
