Sommaire
Cette dépêche présente les changements les plus notables et les plus visibles. En particulier, nous ne détaillons pas ici toutes les corrections de bogues ou les améliorations plus mineures. Pour avoir accès à une liste des changements plus exhaustive, nous vous invitons à consulter le fichier NEWS ou à examiner l'historique du dépôt.
Portage vers GTK+3 officiellement achevé
GIMP 3.0 a été connue comme la version du portage vers GTK+3, vous serez donc heureux d'apprendre que ce portage est officiellement terminé. Pour être tout à fait honnête, quelques avertissements au sujet de code obsolète apparaissent encore çà et là, mais cela n'a rien à voir avec les centaines d'avertissements que nous avions auparavant.
Infrastructure GimpAction
Notre dernier gros chantier était le portage de la gestion des « actions », ce qui correspond dans le vocabulaire de GTK aux raccourcis, à leur mécanisme, mais aussi à la façon dont les menus sont gérés et à la manière d'assigner facilement du code d'action partagé à des widgets (éléments graphiques) génériques. À partir de GTK+3, les actions ont été déplacées vers GLib (GtkAction est devenu GAction) tout en perdant beaucoup de fonctionnalités au passage (en gros tout ce qui était visible par les utilisateurs, c'est à dire les labels, les descriptions, les icônes, ce genre de choses), ou en étant séparées en plusieurs morceaux (le concept de raccourci demeurant lui-même au sein de GTK).
Du coup, nous avons dû réimplémenter tout cela sous forme d'adaptateur autour de GAction, appelé tout simplement GimpAction, car pour nous ces fonctionnalités orientées utilisateur forment un aspect central de ce qui constitue une action (en particulier parce que nous faisons beaucoup de génération d'interface graphique (GUI) et de code, ce qui implique que les éléments comme les labels ou les icônes ne doivent pas être associés à un widget—que ce soit un bouton, une entrée de menu ou quoi que ce soit d'autre—mais plutôt à l'action assignée à ce widget, pour une réutilisation plus aisée et plus générique).
Nous avons aussi dû écrire des adaptateurs pour un certain nombre d'autres widgets, tels que nos propres menus (principalement parce que les menus générés à partir de modèles de menus n'ont plus d'infobulles dans GTK+3, alors que nous utilisons abondamment les infobulles), nos propres modèles de menus (GimpMenu et GimpMenuModel), nos propres barres d'outils et barres de menus (GimpToolbar et GimpMenuBar) et d'autres widgets encore.
Finir tout cela m'a pris environ deux mois, tout en ayant également à m'occuper du code pour d'autres sujets, de la maintenance et des corrections de bogues habituelles. Ennuyeux et fatigant, mais maintenant c'est fait ! 😅
Cela nous ouvre également tout un nouveau monde de possibilités : nous avons ajouté de nouveaux concepts dont nous voulions depuis longtemps, comme la possibilité d'associer à une action à la fois un label court (par ex. pour un usage dans une interface contextuelle comme un menu) et un label long (par ex. pour un usage sans contexte particulier comme la recherche d'actions). Cela ouvre aussi la voie aux futures améliorations que nous avons déjà prévues (par ex. une future barre d'outils personnalisable).
Il nous reste encore un peu de travail à accomplir pour que le nouveau code des menus et des actions soit exactement tel que nous l'imaginions, mais nous en sommes déjà à un point où nous pouvons le présenter au grand jour. Le ressenti ne sera pas très différent pour la plupart d'entre vous (et il est aussi possible que vous découvriez des problèmes), mais notre but était aussi que les choses ne changent pas trop.
À part cela, il y a aussi beaucoup d'améliorations plus immédiates qui valent la peine d'être notées.
Raccourcis multiples par action
Les nouvelles actions GLib/GTK+3 permettent d'assigner plusieurs raccourcis à une même action. Pour le moment, la boîte de dialogue des raccourcis ne vous permet pas de le faire vous-même, mais nous utilisons déjà cette fonctionnalité en interne pour les raccourcis par défaut. Par exemple, les touches du pavé numérique sont physiquement distinctes des touches numérotées de la rangée supérieure (au-dessus des lettres), et nous créions donc des actions similaires en doublon afin de prendre en charge les deux types de touches numériques (parce que pour la plupart des gens, Ctrl-1 doit marcher de la même manière qu'on utilise le pavé numérique ou la rangée supérieure). À présent nous pouvons tout simplement assigner les deux variantes de raccourci à la même action, sans avoir à la dupliquer.
Un autre exemple est qu'il est maintenant possible de prendre en charge les touches média sémantiques (comme les touches média Copy, Cut et Paste qu'on trouve sur certains claviers).
Une boîte de dialogue des raccourcis mise à jour, qui vous permette de définir vos propres raccourcis multiples, ne sera peut-être pas encore disponible pour GIMP 3.0 ; mais avec un peu de chance elle arrivera peu de temps après.
Améliorations pour la recherche d'actions
Maintenant que nous avons notre propre adaptateur pour les actions, nous avons fait en sorte qu'il puisse avoir accès à sa propre position dans les menus afin de pouvoir montrer ce chemin de menu dans la boîte de dialogue de recherche d'actions. Cela aidera les personnes qui préfèrent les menus à s'y retrouver plus facilement.
Boîte de dialogue de recherche d'actions montrant désormais les chemins de menu - GIMP 2.99.16
Vous pouvez également noter la présence d'une petite icône « Manuel » 📓 en haut, à droite de cette capture d'écran. Un clic sur cette icône ouvrira la page du manuel correspondant à une action donnée (s'il n'existe pas encore de page d'aide pour cette action en particulier, vous serez redirigé vers la page d'aide de la recherche d'actions).
Une autre possibilité est de presser la touche F1, ce qui ouvrira la page d'aide de l'action sélectionnée.
Meilleure intégration des opérations GEGL dans l'interface graphique
GEGL est notre moteur de traitement d'image. Les filtres sont implémentés sous forme de modules séparés, que nous appelons des « opérations ». Bien que nous distribuions ce moteur avec une longue liste d'opérations par défaut, les développeurs tiers peuvent implémenter leurs propres filtres, et du coup bénéficier de la génération automatique de boîte de dialogue, de la prévisualisation en direct sur le canevas, de la prévisualisation en rideau, de la sauvegarde des préréglages, de l'historique des réglages antérieurs, et plus encore.
GEGL est un composant majeur depuis GIMP 2.10, et pourtant nous avions encore besoin de code dédié pour insérer les opérations GEGL dans les menus. En ce qui concerne les développeurs de filtres tiers, ils devaient soit implémenter un greffon factice en guise d'adaptateur pour leur opération GEGL, soit se contenter d'être visible uniquement au sein de la longue liste de filtres disponible depuis l'outil des opérations GEGL.
Eh bien, cela a changé car les filtres GEGL ont maintenant eux-mêmes un accès facilité aux menus, à la manière des greffons.
À présent, GIMP lit la clé GEGL "gimp:menu-path" pour ajouter une opération dans les menus. Par exemple, imaginons que j'aie écrit un filtre artistique pour styliser une image et que je veuille le placer dans le sous-menu Filters > Artistic. Le code pour mon opération pourrait donc contenir le code suivant :
gegl_operation_class_set_keys (operation_class,
"name", "Jehan:my-style",
"title", _("My Super Cool Style"),
"description", _("Stylize an image the way I like it"),
"gimp:menu-path", "/Filters/Artistic",
NULL);
Et voilà le résultat :
Ajouter facilement un filtre tiers dans les menus - GIMP 2.99.16
GIMP se chargera de générer automatiquement l'interface graphique suivant les propriétés déclarées dans votre opération.
Bien sûr, vous pouvez également créer vos propres dossiers de menus. Par exemple, si je crée une poignée de filtres destinés spécifiquement à notre projet de film, je pourrai créer un sous-menu "/Filters/ZeMarmot" (ou même un menu de premier niveau—vous pouvez noter le menu « Girin » dans ma capture d'écran, qui correspond déjà à l'endroit où nous installons nos greffons personnalisés).
Nous utiliserons également cette approche pour simplifier le code de base de GIMP, même si pour le moment seulement deux nouveaux filtres GEGL utilisent cette fonctionnalité.
ℹ️ Au sujet des espaces de noms des opérations GEGL : vous avez peut-être remarqué que j'ai utilisé le préfix "Jehan:" pour le nom de mon filtre hypothétique. C'est une façon de définir un « espace de noms » avec un nom unique pour vos filtres et d'éviter ainsi les collisions si quelqu'un venait à implémenter un filtre avec le même nom. Choisissez cet espace de noms avec précaution, et en particulier n'utilisez pas les espaces de noms "gegl:" ou "svg:" qui sont réservés pour les opérations GEGL de base (et seront peut-être même interdits un jour aux opérations tierces).
La deuxième amélioration importante est que vos filtres personnalisés vont maintenant apparaître dans la recherche d'actions (touche / par défaut), que vous les ayez ajoutés ou non à un menu. Cela permet de les chercher et de les exécuter très facilement !
Les filtres tiers peuvent maintenant être recherchés - GIMP 2.99.16
Outils
Outil de texte
Bien que l'éditeur sur canevas de l'outil de texte soit très pratique, il était parfois gênant car encombrant. Dans certaines circonstances vous pouvez préférer voir le canevas nu tout en éditant le texte.
Il est maintenant possible de modifier sa visibilité grâce à la nouvelle option « Montrer l'éditeur sur canevas ».
Montrer/cacher l'éditeur de texte sur canevas - GIMP 2.99.16
Outil pour aligner et distribuer
Cet outil avait été entièrement revu dans GIMP 2.99.14 (NDT : news originale en anglais correspondante).
Dans cette version, nous avons modifié l'option « Utiliser le contour du contenu » afin qu'elle s'applique également à l'objet utilisé comme référence pour l'alignement plutôt qu'uniquement aux objets cibles.
Outil de transformation unifié
Une modification a été soumise afin que la matrice de transformation puisse être sélectionnée à partir de la boîte de dialogue de cet outil accessible sur le canevas. Cela permet de réutiliser plus facilement la matrice en question dans d'autres programmes (par exemple si on désire d'abord tester la transformation et la prévisualiser en direct dans GIMP avant de faire un copier-coller de la matrice).
Space Invasion
Notre projet « space invasion » (« invasion venue de l'espace », un jeu de mots avec l'anglais colorspace signifiant espace de couleurs) vise à assurer la justesse des couleurs partout où nous affichons ou utilisons des couleurs, à choisir des paramètres de couleur par défaut qui soient pertinents, à proposer des options de couleur adaptées, …
Dans la version précédente, une partie du code interne utilisée dans quelques situations supposait encore des entrées ou sorties dans l'espace sRVB. Dans cette version, il est maintenant possible de choisir plus facilement des couleurs de premier et d'arrière-plan en dehors de l'espace sRVB, et la pipette à couleurs affiche les valeurs des couleurs dans l'espace correspondant à l'image.
Toujours en ce qui concerne la pipette à couleurs (et également l'ancrable pour les points d'échantillonnage), un nouveau mode d'affichage « Niveaux de gris (%) » a été ajouté. Il affiche le niveau de gris des pixels choisis si l'image utilisée avait été convertie en niveaux de gris.
Il y a encore beaucoup de travail en cours concernant ces interfaces, par exemple pour s'assurer que les couleurs soient correctement affichées dans les diverses cases de couleurs (pas seulement sur le canevas), ou que le comportement des couleurs dans les widgets partagés soit satisfaisant lors du passage de l'espace de couleurs d'une image à une autre.
Nous voulons aussi être plus explicites sur l'espace de couleurs en cours d'utilisation dans toutes les interfaces partagées où des couleurs peuvent être choisies ou affichées (ancrable de couleurs, couleurs de premier/d'arrière-plan, pipette à couleurs, ancrable pour les points d'échantillonnage, …). Cela constituera un des points principaux de la prochaine version de développement.
Interface graphique
Nouvelle option « Fusionner le menu et la barre de titre »
Dans la boîte de dialogue des Préférences, au niveau du réglage pour les Fenêtres d’images, vous trouverez à présent une nouvelle case à cocher intitulée « Fusionner le menu et la barre de titre » (« Merge menu and title bar »). Cette option permet de basculer vers une décoration côté client pour les fenêtres d'images, ce qui signifie que le menu sera fusionné avec la barre de titre et permettra ainsi d'économiser de la place verticalement.
Réglages des préférences « Fusionner le menu et la barre de titre » - GIMP 2.99.16
Note : cette option ne marche pas pour macOS qui a toujours eu son propre style de menu, spécifique à cette plateforme.
Étant donné que la barre d'en-tête disparaît lorsque la fenêtre est maximisée, si vous avez coché « Afficher la barre de menu » pour l'« Apparence par défaut en mode plein écran » dans Préférences > Fenêtres d'image > Apparence, le menu sera temporairement déplacé en dehors de la barre de titre. Cela rend le menu visible (si l'option correspondante est cochée, ce qui est le comportement par défaut) même en mode plein écran.
Bien sûr, nous savons bien que les décorations côté client sont une fonctionnalité controversée. Certaines personnes les aiment de tout leur cœur et d'autres pas du tout (en particulier parce que la cohérence des styles des fenêtres est perdue puisque les décorations ne sont plus gérées par le gestionnaire de fenêtres). De plus, il nous a été rapporté que dans certains cas le système refuse de retirer ses propres décorations de fenêtre et vous pouvez alors vous retrouver avec deux barres de titre (l'une dessinée par le système et l'autre par GIMP).
Pour ces raisons, cette option est désactivée par défaut.
Thèmes
La version sombre du thème Default a été retravaillée car elle était un peu trop sombre. Pour le moment la version précédente est toujours accessible sous la forme d'un nouveau thème appelé Darker, mais nous ne sommes pas sûrs de la conserver dans l'avenir.
Pendant nos dernières rencontres des développeurs durant lesquelles ce travail a eu lieu, l'idée d'un thème à contraste élevé a aussi été proposée. Nous avons même discuté à un moment donné de la possibilité d'implémenter des réglages pour la personnalisation des couleurs du thème.
À vrai dire, nous ne sommes pas sûrs de ce qu'il en sera pour GIMP 3.0. Cela dépendra en fin de compte de si nous recevons d'autres contributions liées au thème d'ici le moment de la sortie de cette version.
Améliorations pour remplir/tracer la sélection/le chemin
Les boîtes de dialogues « Tracer/Remplir le contour de la sélection » ou « Tracer/Remplir le chemin » proposaient de tracer (ou de remplir) soit avec une « Couleur pleine » (en fait la couleur de premier plan), soit avec un « Motif ». Nous avons séparé la « Couleur pleine » en une « Couleur de premier plan » et une « Couleur d'arrière-plan », ce qui vous évitera d'avoir à les échanger.
En outre, les boîtes de dialogue « Tracer la sélection » et « Tracer le chemin » en particulier ont été réorganisées sous forme d'un sélecteur de réglages afin de rendre les deux options « Ligne » et « Outil de peinture » plus faciles à utiliser.
Grâce à la place ainsi économisée, nous n'avons plus à cacher les réglages de « Style de ligne » sous un élément dépliable, ce qui permet de mettre plus en avant les options pour le rendu de ligne.
Réorganisation des boîtes de dialogue pour le traçage - GIMP 2.99.16
Option de remplissage de calque « Gris moyen (CIELAB) »
Lors de la création d'une nouvelle image ou d'un nouveau calque, le champ « Remplir avec » vous permet de choisir la couleur du calque ainsi créé parmi les couleurs de premier et d'arrière-plan, le blanc, le noir, la transparence ou un motif. Nous avons ajouté « Gris moyen (CIELAB) » (en anglais « Middle grey (CIELAB) ») qui correspond à 50% de luminosité perçue (le L* de CIELAB ou CIELCh, lightness en anglais), soit 18.42% de luminance.
Bien que le concept de « gris moyen » puisse avoir différentes valeurs selon la définition choisie, celle ci-dessus est l'une des plus communément admises. Elle est censée correspondre à une perception à mi-chemin entre l'obscurité et la lumière pour l'œil d'un observateur humain moyen.
Formats de fichiers
Nous devons un gros morceau du travail sur les formats de fichiers à Alx Sa (alias Nikc dans les dépêches précédentes), qui a un talent certain pour ajouter la prise en charge de formats divers et variés et pour améliorer les prises en charge qui existent déjà. Et c'est un super travail, alors bravo Alx ! 👍
FITS
Le format FITS est un format d'image surtout utilisé en astronomie.
Nous avions l'habitude d'utiliser notre propre code pour la prise en charge de ce format, mais nous utilisons maintenant cfitsio, une bibliothèque maintenue par la NASA.
Cela nous permet d'importer des fichiers FITS compressés (GZIP, HCOMP, PLIO, RICE) en 8/16/32 bits et en virgule flottante à double précision. De manière générale, cela va grandement améliorer notre prise en charge de ce format.
Étant donné que nous utilisons désormais une bibliothèque externe, la prise en charge du format FITS devient optionnelle (cela est surtout vrai pour les paquets des distributions Linux ; cette prise en charge est toujours présente dans nos propres paquets).
Nous adressons également un grand merci à Siril (l'outil de traitement d'images astronomiques) dont les personnes réalisant le développement ont échangé avec nous pour améliorer cette prise en charge dans GIMP.
PSD (et un peu de TIFF et JPEG)
Les chemins utilisés pour le découpage (clipping) peuvent maintenant être importés depuis—et exportés vers—des fichiers PSD !
Si votre image comporte un chemin, une boîte de dialogue pour l'exportation au format PSD vous proposera d'« Assigner un chemin de découpage » (« Assign a Clipping Path »), et un menu combiné vous permettra de choisir le chemin à utiliser.
Exporter un chemin de découpage - GIMP 2.99.16
Ce chemin de découpage peut être utilisé dans les programmes qui prennent en charge les chemins de découpage ; par exemple Scribus (publication assistée par ordinateur) énumère déjà tous les chemins en tant que chemins utilisables comme chemin de découpage mais surlignera en vert le chemin de découpage sélectionné, ce qui permet de mieux repérer le chemin que vous voulez utiliser à cette fin.
Utilisation d'un chemin de découpage dans Scribus (notez en particulier le chemin surligné en vert) - GIMP 2.99.16
De la même manière, lors d'une importation, toute information concernant un chemin de découpage stockée dans le fichier PSD sera réutilisée par défaut lors de l'exportation.
Un autre changement intéressant est que, lors de l'importation, dans le cas où certaines fonctionnalités du format PSD ne seraient pas prises en charge, une boîte de dialogue d'avertissement de problème de compatibilité sera affichée et fera la liste de toutes les fonctionnalités manquantes :
Avertissements de problèmes de compatibilité lors de l'importation d'un fichier PSD - GIMP 2.99.16
De cette manière, vous pourrez prendre une décision en connaissance de cause lorsque vous travaillerez avec des fichiers échangés au format PSD.
Vous pouvez noter que la boîte de dialogue pour l'exportation a une nouvelle « Note de compatibilité » concernant les anciens modes de calques. En effet, certaines personnes ont remarqué qu'elles obtenaient une meilleure compatibilité en exportant des fichiers au format PSD et en les ouvrant à nouveau dans Photoshop.
Et pour finir, une nouvelle procédure PDB (PDB = GIMP's Procedure DataBase) intitulée "file-psd-load-metadata" a été créée pour permettre aux autres greffons de déléguer le chargement des métadonnées PSD au greffon PSD. En effet, un usage répandu parmi les différents formats de fichiers est de stocker des métadonnées qui leur sont propres sous le format de métadonnées propriétaire de Photoshop. Nous avons déjà implémenté deux usages de ce type :
Les images au format TIFF peuvent contenir des ressources propriétaires au niveau de l'image dans les métadonnées TIFFTAG_PHOTOSHOP, ainsi que des ressources au niveau du calque (par exemple des calques PSD au lieu de pages TIFF) dans les métadonnées TIFFTAG_IMAGESOURCEDATA. GIMP prend maintenant en charge ces deux types de métadonnées et chargera ce qu'il est capable d'utiliser.
Les images au format JPEG peuvent contenir des métadonnées PSD uniquement au niveau de l'image, comme les chemins par exemple. Ces métadonnées seront maintenant également chargées.
De même qu'avec le greffon PSD lui-même, si certaines de ces métadonnées ne sont pas prises en charge, une boîte de dialogue de compatibilité sera affichée.
Cela ouvre la voie à de nouvelles perspectives pour la prise en charge des formats JPEG et TIFF (par rapport à leurs ressources spécifiques au format PSD propriétaire), car ils bénéficieront immédiatement du même niveau de prise en charge que le greffon PSD plutôt que de s'appuyer sur du code dupliqué.
JPEG
En plus des améliorations relatives à la gestion des métadonnées, l'option « 4:2:2 horizontal (chroma halved) » a été renommée en « 4:2:2 (chroma halved horizontally) » et l'option « 4:2:2 vertical (chroma halved) » a été renommée en « 4:4:0 (chroma halved vertically) ». (NDT : intitulés des options gardés en anglais dans la dépêche.)
Nos recherches indiquent que cela correspond à la manière la plus fréquente de dénommer ces options de nos jours.
JPEG-XL
Nous avons ajouté une première prise en charge pour l'exportation au format CMJN(A) : les données pour le noir et l'alpha sont enregistrées dans des canaux supplémentaires et le profil de simulation est également sauvegardé.
D'après les personnes ayant développé le cahier des charges du format, JPEG-XL ne prend pas en charge la conversion « naïve » vers CMJN, ce qui rend nécessaire de disposer d'un profil pour l'exportation. L'option « Exporter au format CMJN » sera désactivée si aucun profil de simulation CMJN n'est présent.
DDS
Nous permettons maintenant la prise en charge d'OpenMP quand cette interface de programmation est disponible sur la machine de compilation. Cela signifie en particulier que le traitement en parallèle est activé, ce qui devrait améliorer la vitesse de traitement dans certains cas.
Nouveaux formats d'images pris en charge : PAM, QOI, Amiga IFF/ILBM, DCX
Nous avons récemment ajouté la prise en charge de l'importation et de l'exportation pour les formats suivants :
-
PAM (niveaux de gris et RVB, avec ou sans transparence) : essentiellement des fichiers PPM avec un format d'en-tête différent et une prise en charge de l'alpha et du 16 bits.
-
QOI : le format intitulé de manière humoristique « Quite OK Format » (« format plutôt convenable ») qui permet une compression sans perte des images matricielles en couleur (8 bits par canal), avec ou sans canal alpha.
Nous avons ajouté la prise en charge de l'importation seule pour les formats suivants :
-
Amiga IFF/ILBM : première prise en charge pour l'importation des fichiers ILBM indexés, Amiga PBM, et ACBM.
-
DCX : des conteneurs qui emmagasinent jusqu'à 1023 fichiers PCX.
Il peut sembler inutile de prendre en charge de tels formats, étranges, anciens, voire parfois oubliés, mais c'est au contraire important (au moins en ce qui concerne l'importation). Cela est utile pour l'archivage, pour pouvoir afficher de vieilles images qui ont pu être créées il y a des années, et pour le réemploi et le travail à partir de données existantes.
Idéalement notre objectif est que GIMP puisse importer n'importe quel format ayant existé un jour !
Note : certaines de ces nouvelles prises en charge ne sont peut-être pas encore incluses dans nos paquets officiels (par exemple Amiga IFF/ILBM), mais elles devraient l'être bientôt.
API des greffons
L'interface de développement des greffons continue de progresser vers son état final, bien qu'elle demeure l'un des derniers gros chantiers en cours maintenant que le portage vers GTK+3 est terminé.
Les données des ressources ont maintenant leur propre classe
Les greffons GIMP faisaient référence aux diverses ressources (brosses, polices, gradients, palettes, motifs, etc.) par leurs noms. Nous avons fait le choix de créer des classes spécifiques (respectivement GimpBrush, GimpFont, GimpGradient, GimpPalette et GimpPattern) dans libgimp pour ces données, à partir d'une classe parente commune GimpResource. Cela transforme cette partie de l'API en une interface orientée objet (telle qu'elle existe déjà pour les images, les calques, …) ce qui la rend bien plus pratique pour les modules de liaison.
De plus, nous utilisons maintenant des identifiants uniques pour chaque ressource, sans se baser sur leurs noms. Bien que cela concerne surtout le côté libgimp pour le moment, nous prévoyons de faire en sorte que les noms soient également moins utilisés comme identifiants dans le code de base. En effet, cela résulte bien trop facilement en des collisions de noms, surtout si vous échangez des données avec d'autres personnes (il est aisé de trouver des brosses ou des polices personnalisées créées par des personnes différentes mais qui utilisent des noms identiques). Nous nous efforçons de rendre GIMP plus robuste face à ce genre de problèmes concrets de collisions de noms.
Amélioration de la régionalisation des greffons
Nous avons revu en partie les règles de régionalisation des greffons. Alors que les chaînes de caractères des menus étaient régionalisées par l'application de base elle-même, le reste était régionalisé par le processus du greffon. Cela a toujours été une source de confusion pour les développeurs tiers (« Est-ce que je dois utiliser _() ou N_() pour traduire les chaînes de caractères ? »). À présent cela est beaucoup plus simple : les greffons prennent entièrement en charge leur propre régionalisation, et passent ainsi systématiquement des chaînes de caractères déjà traduites au processus de base. Cela implique aussi qu'un changement des réglages de langue de GIMP déclenche un rechargement des tous les enregistrements des greffons (pour mettre à jour les chaînes de caractères).
En plus de simplifier les règles, cela permet aussi d'éviter de possibles collisions parmi les noms de catalogue pour gettext (dans le cas où deux greffons utiliseraient le même nom de catalogue, cela n'est plus un problème car chaque processus gère son propre catalogue).
Et pour finir, même si nous recommandons encore d'utiliser gettext (en effet nous fournissons également des fonctions permettant aux greffons de facilement mettre en place leur régionalisation avec gettext), cela donne une plus grande liberté aux personnes développant des greffons tiers pour choisir leur propre infrastructure de régionalisation si elles préfèrent un autre système.
Tous ces changements s'inscrivent dans un travail de plus longue haleine consistant à déplacer les greffons vers un nouveau système d'extensions autonomes plus faciles à partager et à installer.
Des types d'arguments plus spécialisés pour les greffons
GStrv a été ajouté dans GIMP 2.99.10, mais il n'était pas sérialisé dans les fichiers de configuration (notre infrastructure pour conserver les réglages des greffons d'une exécution à l'autre) jusqu'à cette version. Un premier usage très sympa de cette fonctionnalité concerne la console Script-fu, qui dispose maintenant d'un historique des commandes exécutées.
De plus les greffons ont maintenant accès aux arguments GBytes pour tous les cas où nous utilisions à mauvais escient des tableaux d'entiers non signés sur 8 bits à leur place pour la représentation de données binaires (ou plus généralement de données personnalisées pouvant être de n'importe quel type, depuis du texte jusqu'à du binaire). Le type GimpUint8Array a été retiré des types d'arguments possibles pour les greffons et tous ses emplois ont été remplacés.
Et plus encore…
D'autres fonctions ont été ajoutées, par exemple pour améliorer les capacités de génération d'interface graphique depuis les greffons. Quelques problèmes d'encodage ont été résolus et les annotations et l'usage de plusieurs fonctions ont été clarifiés.
Pour une liste plus exhaustive des fonctions ajoutées, retirées ou modifiées, nous vous recommandons de consulter le fichier NEWS (en anglais).
GEGL, babl
Comme d'habitude, cette version de GIMP s'accompagne de nouvelles versions de babl et de GEGL :
babl 0.1.104 et 0.1.106 ont vu le code des tables de correspondance (LUT) amélioré ainsi qu'un démarrage plus rapide en mettant en cache des matrices RVB vers XYZ équilibrées.
GEGL 0.4.44 et 0.4.46, en plus des correctifs de bogues habituels, ont commencé à ajouter la clé "gimp:menu-path" à certaines opérations, ont amélioré gegl:ff-load et gegl:ff-save pour pouvoir les compiler avec FFmpeg 6.0 (bien que gegl:ff-save ne marche toujours pas parfaitement avec cette version de FFmpeg), et ont ajouté deux opérations.
La première de ces opérations est gegl:chamfer : une nouvelle opération qui utilise gegl:distance-transform et gegl:emboss, basée sur les recherches de LinuxBeaver pour modéliser différents biseaux (bevels) combinés avec des effets de flou. Cette opération est encore considérée expérimentale et n'est donc présente que dans les versions de développement (en activant l'option workshop de GEGL).
Application de gegl:chamfer à un texte pour un effet de biseau - GIMP 2.99.16
La seconde de ces opérations est gegl:local-threshold : une opération de seuillage prenant en compte le voisinage local et avec anticrénelage optionnel. L'opération est équivalente à l'application d'un filtre « Renforcer la netteté » avec un rayon important, suivie d'un agrandissement de l'image, d'un effet de seuil, puis d'une réduction de l'image inverse de l'agrandissement précédent.
Si vous disposez d'une photo et que vous voulez réaliser un effet de seuil correct dans les zones d'ombre et de lumière, cette méthode donne des résultats bien meilleurs que l'effet de seuil par défaut. Elle détermine des niveaux de seuils adaptés à l'échelle du pixel, en se basant sur une moyenne gaussienne dans un voisinage déterminé par le rayon. De plus, elle permet de créer des filtres de seuil sans crénelage (si le rayon est réglé à 0, le comportement est similaire à l'opération de seuil par défaut).
Du point de vue de l'expérience utilisateur, la seule chose qui manque encore pour que ce nouveau filtre remplace complétement le filtre de seuil actuel est de pouvoir spécifier la conversion rvb ⇒ niveaux de gris, et les éléments additionnels de l'interface graphique seraient alors les options pour le seuillage.
Notez bien cependant que l'anticrénelage est obtenu par un agrandissement suivi d'une réduction de l'image en entrée—du coup l'utilisation de réglages élevés ne produit qu'un gain de qualité relativement modeste.
À gauche : image originale ; à droite, en haut : résultat avec le filtre de seuil actuel ; à droite, en bas : résultat avec le nouvel outil de seuillage local - GIMP 2.99.16
Statistiques de sortie
Depuis GIMP 2.99.14 :
- 105 rapports ont été fermés avec l'étiquette RÉSOLUS (FIXED) dans la version 2.99.16.
- 123 demandes de fusion (merge requests) ont été acceptées.
- 1115 commits ont été poussés en amont.
- 25 traductions ont été mises à jour : allemand, basque, bulgare, catalan, chinois (de Chine), chinois (de Taïwan), danois, espagnol, esperanto, français, géorgien, grec, hongrois, islandais, italien, lituanien, persan, polonais, portugais, roumain, russe, slovène, suédois, turc, ukrainien.
67 personnes ont apporté des modifications ou des correctifs à la base de code de GIMP 2.99.16 (l'ordre est déterminé par le nombre de commits) :
- 34 développeurs : Jehan, Alx Sa, Michael Natterer, Jacob Boerema, Simon Budig, Luca Bacci, Niels De Graef, Daniel Novomeský, Lloyd Konneker, Øyvind Kolås, Lukas Oberhuber, Ian Martins, programmer-ceds, Andras Timar, Andre Klapper, Carlos Garnacho, Idriss Fekir, Jordi Mallach, Sabri Ünal, Shubham, Stanislav Grinkov, Stephan Lenor, Venkatesh, kotvkvante, lapaz, lillolollo, programmer_ceds, valadaptive, 依云, Anders Jonsson, Jordi Mas, Richard Szibele, Tomasz Golinski et Florian Weimer.
- 31 traducteurs : Martin, Yuri Chornoivan, Ekaterine Papava, Alexander Shopov, Hugo Carvalho, Jordi Mas, Sabri Ünal, Rodrigo Lledó, Asier Sarasua Garmendia, Anders Jonsson, Alan Mortensen, Cristian Secară, Sveinn í Felli, dimspingos, Alexandre Prokoudine, Balázs Úr, Chao-Hsiung Liao, Piotr Drąg, Tim Sabsch, Kristjan SCHMIDT, Luming Zh, Marco Ciampa, Alexandre Franke, Aurimas Černius, Balázs Meskó, Christian Kirbach, Danial Behzadi, Emin Tufan Çetin, MohammadSaleh Kamyab, Zurab Kargareteli et حجتاله مداحی.
- 10 créateurs de ressources (icônes, thèmes, curseurs, écran d'accueil, métadonnées, …) : Jehan, Michael Natterer, Alx Sa, Stanislav Grinkov, Lloyd Konneker, Ville Pätsi, Aryeom Han, Daniel Novomeský, Anders Jonsson et Mark.
- 5 contributeurs à la documentation : Jehan, Lloyd Konneker, Anders Jonsson, Corey Berla et Michael Natterer.
- 15 contributeurs à la compilation ou l'intégration continue : Jehan, Alx Sa, Jacob Boerema, Michael Natterer, Daniel Novomeský, Lloyd Konneker, Michael Schumacher, Stanislav Grinkov, Niels De Graef, Simon Budig, Lukas Oberhuber, Florian Weimer, Luca Bacci, lillolollo et Jordi Mallach.
Contributions sur d'autres dépôts dans le GIMPvers (l'ordre est déterminé par le nombre de commits) :
- 1 contributeur à babl 0.1.104 et 0.1.106 : Øyvind Kolås.
- 13 contributeurs à GEGL 0.4.44 et 0.4.46 : Øyvind Kolås, Marco Ciampa, Martin, Asier Sarasua Garmendia, Ekaterine Papava, Piotr Drąg, Yuri Chornoivan, Alexandre Prokoudine, Jan Tojnar, Rodrigo Lledó, Sabri Ünal, Tim Sabsch et dimspingos.
- 2 contributeurs à ctx depuis la version 2.99.14 : Øyvind Kolås et Carlos Eduardo.
- 3 contributeurs à
gimp-macos-build (scripts de compilation pour macOS) depuis la version 2.99.14 : Lukas Oberhuber, Kyungjoon Lee et Mingye Wang.
- 2 contributeurs (et un bot) à la version beta du flatpak: Jehan, Daniel Novomeský et flathubbot.
- 7 contributeurs au site web principal (https://www.gimp.org/) depuis la version 2.99.14 : Jehan, Sabri Ünal, Jacob Boerema, Aryeom Han, Michael Schumacher, lillolollo et Tim Spriggs.
- 9 contributeurs au site web de développement depuis la version 2.99.14 : Jehan, Bruno Lopes, Jacob Boerema, Krek Krek, Mark, Alx Sa, GoldenWon, Michael Schumacher et kotvkvante.
- 16 contributeurs à la version 3.0 de notre documentation depuis la version 2.99.14 : Andre Klapper, Jacob Boerema, Anders Jonsson, dimspingos, Yuri Chornoivan, Jordi Mas, Nathan Follens, Tim Sabsch, حجتاله مداحی, Alexander Shopov, Balázs Úr, Danial Behzadi, Hugo Carvalho, Martin, Piotr Drąg et Rodrigo Lledó.
Ensuite, n'oublions pas de remercier toutes les personnes qui nous aident au triage dans Gitlab, signalent des bogues et discutent avec nous des améliorations possibles. Et bien sûr, notre communauté est profondément reconnaissante aux guerriers de l'Internet qui gèrent nos différents canaux de discussion ou comptes de réseaux sociaux tels que Ville Pätsi, Liam Quin, Michael Schumacher et Sevenix !
Remarque : compte tenu du nombre de pièces qui composent GIMP et son environnement, et de la manière dont nous obtenons des statistiques via des scripts pour git, des erreurs peuvent se glisser dans ces statistiques. N'hésitez pas à nous signaler si nous avons manqué ou mal classé certains contributeurs ou contributions.
Nouvelles de l'équipe et procédure de sortie
Notre procédure de sortie s'améliore avec chaque nouvelle version. Je voudrais remercier nos testeurs qui ont fait un super travail en éliminant les quelques obstacles qui bloquaient la sortie de GIMP 2.99.16, ainsi que les personnes qui ont assuré le suivi de ces problèmes, ont géré les réponses techniques, créé ou mis à jour des paquets, et plus encore.
Un grand merci en particulier à (par ordre alphabétique) : Alx Sa, Anders Jonsson, Daniel Novomeský, Hubert Figuière, Jacob Boerema, Liam Quin, lillolollo, Luca Bacci, Lukas Oberhuber, Mark Sweeney, Sevenix, ShiroYuki_Mot et Uzugijin !
Pour rappel, si vous êtes désireux de nous aider à améliorer GIMP en participant aux tests de la version à sortir, merci d'ouvrir un rapport sur le traqueur du site des développeurs avec les informations suivantes :
- le système d'exploitation (Linux, Windows, macOS, *BSD…) sous lequel vous ferez les tests, si possible avec des détails (quelle distribution Linux et quelle version ? quelle version de Windows ou de macOS ? …) ;
- les architectures sur lesquelles vous ferez les tests (x86, ARM… 32 ou 64 bits) ;
- si vous testerez les paquets pré-compilés ou depuis les fichiers sources (avec votre propre compilation faite sur mesure).
Nous vous inclurons alors dans le test de la prochaine version à sortir (à la fois pour les versions stables et de développement).
Ce que nous attendons des personnes faisant les tests :
- Assurez-vous de recevoir les notifications de Gitlab quand votre pseudonyme est mentionné (nous vous recommandons de régler votre niveau global de notification (Global notification level) sur « Participate » ou « On mention »).
- Suivez le rapport de sortie pour être au courant de ce qui se passe et de quand nous avons besoin de vous.
- Les rapports de sortie ne sont pas un endroit où nous apprenons aux gens comment utiliser les fonctions de base d'un ordinateur. Les personnes réalisant les tests n'ont pas besoin d'être des développeurs ou développeuses, mais elles doivent être capables de suivre des instructions techniques basiques, de faire des retours plus utiles que « ça ne marche pas », et de manière générale d'interagir avec les personnes participant au développement.
- Soyez agréables et accueillants : tout le monde ici est bénévole, les testeurs aussi bien que les développeurs. Ceci est un logiciel libre et communautaire, pas un travail sans âme. 🤗
Autour de GIMP
Des nouvelles des miroirs
Le Fremont Cabal Internet Exchange a ajouté un nouveau miroir de téléchargement pour distribuer GIMP, basé à Sheffield, dans le Yorkshire du Sud (Royaume-Uni). Avec 11 miroirs sur un total de 41, ils sont clairement notre plus gros sponsor pour les miroirs ! Merci FCIX !
Les miroirs sont importants, car ils aident le projet en se partageant la charge des dizaines de milliers de téléchargements quotidiens. De plus, avoir des miroirs distribués autour du monde permet de s'assurer que tout le monde peut télécharger GIMP rapidement.
Des nouvelles des livres
Sabri Ünal a fait un super travail de recherche bibliographique et a ajouté 39 livres (et mis à jour encore davantage) sur notre page « Des livres sur GIMP » (« Books About GIMP »). Nous ne faisons pas la liste de tous les changements ici car ils sont trop nombreux, mais vous pouvez lire les descriptions détaillées des demandes de fusion correspondantes (!93 et !98, en anglais).
Du coup, notre page des livres est de plus en plus à jour, avec des publications très récentes. Plutôt sympa ! 📚🤓
Nous rappelons à tous que les ajouts de livres sont les bienvenus. Si vous connaissez un livre sur GIMP qui n'est pas encore présent dans la liste, il vous suffit de rapporter les mêmes informations que pour les autres livres de la liste. Merci !
Télécharger GIMP 2.99.16
GIMP 2.99.16 est pour le moment uniquement disponible pour Linux et Windows. Notre système d'empaquetage pour macOS est temporairement bloqué à cause de notre incapacité à certifier les paquets tant que la Fondation GNOME n'aura pas résolu un problème avec son compte Apple. Nous vous tiendrons au courant.
Mise à jour le 11 juillet : GIMP 2.99.16 est maintenant disponible pour Linux, Windows et macOS !
Vous pourrez trouver tous les exécutables officiels sur le site officiel de GIMP (gimp.org) :
- Flatpak de développement Linux
- Installateur Windows
- Packages macOS DMG pour le matériel Intel
- Packages macOS DMG pour le matériel Apple Silicon
D'autres paquets réalisés par des tiers devraient bien sûr suivre (packages des distributions Linux ou *BSD, etc.).
Et après ?
Bien que notre feuille de route présente encore quelques autres éléments à finir, les deux plus gros chantiers pour la prochaine version sont la transformation de l'API—qui est déjà bien avancée mais est assez importante pour justifier que l'on s'y attarde pour vérifier les détails—, et le projet de Space Invasion (pour s'assurer que toutes les fonctionnalités liées aux couleurs sont fiables).
Nous en sommes donc à un point où le développement se « stabilise ». Nos exigences pour les dépendances étaient précédemment basées sur « Debian testing » (quelle que soit la version de Debian à laquelle cela correspondait), mais nous avons récemment figé les versions de nos dépendances sur la fraîchement sortie Debian 12 (bookworm). Cela veut dire que nous n'incrémenterons pas les versions minimales de nos dépendances au-delà de ce qui est présent dans Debian 12 (sauf pour les dépendances optionnelles, et même pour elles uniquement de manière exceptionnelle et avec de bonnes raisons). C'est parce que nous prévoyons de sortir prochainement la version suivante que nous devons nous assurer que GIMP puisse être empaqueté pour toutes les distributions relativement récentes.
Bien sûr, pour nos propres paquets (Windows, macOS et Flatpak), nous continuerons tout de même à utiliser les versions les plus récentes des dépendances.
N'oubliez pas que vous pouvez faire un don et financer personnellement les développeurs de GIMP, c'est un moyen de donner en retour et d'accélérer le développement de GIMP. L'engagement de la communauté aide le projet à se renforcer ! 💪🥳
Aller plus loin
Annonce officielle de GIMP 2.99.16 (en anglais)
