Note : cette dépêche est une traduction de l'annonce officielle de la sortie de GIMP 2.99.16 du 9 juillet 2023 (en anglais). Celle-ci ayant été rédigée par Jehan (mainteneur du projet avec Michael Natterer), le pronom "je" dans la traduction ci-dessous désigne donc Jehan.
Maintenant plus proche que jamais d'une version candidate pour GIMP 3.0, nous vous présentons la dernière version de développement : GIMP 2.99.16 !
Nous sommes très heureux de pouvoir vous présenter dans cette dépêche certains des aspects les plus remarquables et les plus intéressants de cette mise à jour.
Nouvel écran d'accueil de la version de développement par Aryeom - GIMP 2.99.16
Note : l'anecdote derrière cet écran d'accueil est la préparation par Aryeom d'un Wilber en pâte à pizza pendant le premier soir de la Wilber Week. La pâte cuite au four nous a accompagnés pendant tout notre séjour. Cette version de GIMP est surnommée l'« édition Wilber Week 2023 » en hommage à notre rencontre des contributeurs, qui a été un grand succès.
Sommaire
-
- Portage vers GTK+3 officiellement achevé
- Meilleure intégration des opérations GEGL dans l'interface graphique
- Outils
- Space Invasion
- Interface graphique
- Améliorations pour remplir/tracer la sélection/le chemin
- Option de remplissage de calque « Gris moyen (CIELAB) »
- Formats de fichiers
- API des greffons
- GEGL, babl
- Statistiques de sortie
- Nouvelles de l'équipe et procédure de sortie
- Autour de GIMP
- Télécharger GIMP 2.99.16
- Et après ?
- Aller plus loin
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", "<Image>/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 "<Image>/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éesTIFFTAG_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)
# UI
Posté par Psychofox (Mastodon) . Évalué à 5.
Je vois qu'il y a un certain nombre de changement sur des points d'interface. À tord où à raison, l'UX est souvent un sujet qui est mis en avant par les détracteurs de Gimp. Comment sont prises les décisions à ce sujet dans le projet Gimp? Disposez-vous d'aide de la part de spécialistes en UX pour améliorer ces points? Les changements sont-ils décidés à partir de tickets du gestionnaire de suivi sur gitlab créés par des utilisateurs? Où sont-ce des décisions propres du noyau dur des contributeurs?
[^] # Re: UI
Posté par orfenor . Évalué à 5.
Jehan a déjà répondu dans une dépêche précédente :
[^] # Re: UI
Posté par steph1978 . Évalué à 2. Dernière modification le 26 juillet 2023 à 18:44.
Moi ça me choque pas bien au contraire puisqu'il s'agit de rivaliser avec des PhotoShop et autres.
Et pour des besoins plus amateurs, j'aime bien utiliser XnView.
EDIT: bon ok, je me rends compte que ce n'est pas open source. Mon adoption remonte à un temps où je ne regardais pas trop cet aspect. Un des rares freeware pour lequel j'ai fait une donation. Au moins c'est 🇫🇷
[^] # Re: UI
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 26 juillet 2023 à 21:49.
Salut,
Je sais pas s'il y a quiproquo ou les infos se déforment juste avec le temps, mais l'histoire du designer, je me demande d'où elle vient, car ça me dit rien:
Alors non. On a eu un spécialiste à une époque, pendant plusieurs années. Je l'ai connu à mes tout-débuts chez GIMP. Par contre il était imbuvable, il se prenait pour une star et les développeurs pour ses sous-fifres (ma première réunion en "réel" avec lui, lors d'un Libre Graphics Meeting, il commence en traçant un triangle sur le tableau et en expliquant qu'en haut, y a le designer qui décide, dans un autre coin, y a les développeurs qui doivent simplement implémenter ce que le designer décide sans poser de questions, et dans le dernier coin, y a les utilisateurs qu'il faut surtout pas écouter parce qu'eux-mêmes savent pas ce qu'ils veulent; j'étais atterré 🤦), et surtout il bloquait les arrivées de nouvelles fonctionnalités car tout ce qui touchait à la GUI devait passer par lui (or je l'ai connu à une époque où il était moins actif, donc ça bloquait dur; je considère perso qu'il a fait perdre quelques années à GIMP sur certaines choses).
J'ai personnellement eu quelques altercations email avec lui à cause de son comportement et il a fini par partir en écrivant un long email pour expliquer à quel point les anciens mainteneurs étaient bons (ceux que j'ai pas connu mais que tout le monde m'a dit être plutôt abrasifs… vous connaissez tous la réputation des méchants développeurs de GIMP qui apparemment date d'avant moi puisque moi j'ai surtout connu les gentils, mais une réputation, ça a la vie dure…) et nous mauvais. En fait, il serait pas parti, je serais sûrement parti moi-même à un moment donné (j'ai une habitude de pas supporter les injustices et mauvais traitements; j'ai déjà démissionné professionnellement sans demander mon reste pour cause de mauvais managers; alors imaginez dans ce qui à l'époque était principalement un hobby). Donc ça tombe bien.
Donc c'est la seule histoire de designer problématique que j'ai par rapport à GIMP. D'ailleurs je ne suis pas sûr en avoir jamais parlé en détail sur un forum public à ce jour (par contre c'est un sujet qu'on a de temps en temps en privé ou sur IRC) mais bon, ça fera bientôt 10 ans, donc bon… maintenant c'est peut-être OK de raconter ça. Néanmoins ça ne veut absolument pas dire qu'on est frileux par rapport aux designers. Dans ma vie professionnelle, j'ai travaillé avec de bons designers et je suis plus que disposé à continuer à travailler avec d'autres. "Bons" designers, ça veut dire quelqu'un qui sait travailler avec des développeurs (et des utilisateurs), qui sait aussi écouter, recevoir des retours et remarques et les prendre en compte pour modifier une spécification. Et non quelqu'un qui se prend pour un dieu. De même qu'un bon développeur n'est pas un génie du code mais quelqu'un qui sait écouter et échanger. De même pour tous les métiers d'ailleurs. En gros je met en avant les qualités sociales, l'ouverture et la bienveillance d'une personne avant les compétences pures et dures (je sais que ce n'est pas de l'avis de tous; certains pensent encore que le concept du "génie connard" est bien, à savoir qu'on peut tout laisser passer humainement de la part de quelqu'un qu'on considérerait excellent techniquement dans son métier; j'ai encore des discussions régulièrement sur ce sujet et c'est aussi un sujet classique de l'imaginaire populaire, notamment avec la télé/ciné, du héros antipathique au possible mais à qui on pardonne tout parce qu'il sauve le monde/les gens/l'entreprise).
Sinon oui, c'est sûr, de temps en temps, on a des "designers" qui passent une fois, disent qu'ils veulent tout changer puis reparaissent jamais (sûrement en se demandant pourquoi on laisse pas tout de côté pour se concentrer sur eux et qu'on réimplémente pas GIMP immédiatement, entièrement sur la base des 2 paragraphes qu'ils ont écrit en 10 minutes dans un rapport). Ça arrive souvent. Mais ça nous rend pas frileux pour autant. Ça c'est le quotidien. De même qu'on a très régulièrement les designers du dimanche qui font un message (ou un thread) sur twitter et considèrent que c'est suffisant (en général ceux-ci font la même chose pour plein de projets; leur but semble juste de montrer à quel point ils sont bons en critiquant des gros projets avec un semblant de critiques constructives, mais ils ne font que gratter la surface, sans jamais rentrer dans la partie réellement constructive: intéragir, discuter avec les développeurs et contribuer — tout court déjà, encore moins en profondeur —, en détail sur des points précis — et pas des concepts abstraits et généraux — et en itérant).
Enfin bon, au final, si, bien sûr qu'on veut des designers dans l'équipe. Mais ils seraient dans l'équipe, des membres à part entière comme les autres et pas des divinités à adorer (comme certains semblent croire que doive être le rôle de designer). Qu'on me dise pas que ça existe pas. J'ai déjà travaillé avec de tels designers!
Et ils doivent y mettre du leur, pas juste déposer 3 phrases bateaux et un peu vague dans un rapport ou sur Twitter et croire que leur job est fait.
On a bien plus que 2 contributrices de rapports de bug précis. On a des dizaines de messages par jour sur notre outil de suivi, et pas mal d'habitués qui y font des rapports très réguliers et parfois très détaillés.
Vrai ou non, ce n'est pas une caractéristique de cette personne. Si je suis en couple, je n'appelle pas ma compagne "ma compagne" (allez, disons sauf pour simplifier dans de rares cas, genre en face d'administrations) mais par son prénom et si j'intéragis professionnellement, c'est par ses compétences professionnelles. Être un ou une compagne n'est pas une caractéristique qui a le moindre intérêt et je préfère quand les gens ne voient pas autrui comme étant la compagne ou le compagnon d'un autre. Surtout quand ce sont des personnes avec des compétences techniques très importantes et pointues dont on parle. Cela ne fait que diminuer la valeur de tout le monde.
Je pense que le monde irait mieux si on ne qualifiait pas les gens par des caractéristiques qui n'ont aucun intérêt (compagne/compagnon de, femme/mari de, fils/fille de, père/mère de…). Sans compter que la vie privée des gens n'a rien à faire dans leur vie professionnelle.
En gros, cette remarque en aparté n'a aucun intérêt et n'a absolument rien à faire là. 🤔
Ça a en effet toujours été vrai que GIMP est un logiciel pro (dans l'industrie, on appelle même cela un "logiciel métier"). Et donc c'est vrai qu'on va prendre bien plus en considération les besoins pros très bien expliqués avec des cas d'usage très concrets. On a beaucoup de pros qui font des retours très détaillés et qui suivent le projet de près. 😄
Et beaucoup de fonctionnalités sont demandées par des pros qui ont besoin d'utiliser des fonctionnalités avancées. Ensuite comme GIMP est un logiciel de graphisme générique, cela recoupe diverses industries. En plus des usages évidents (photographie, peinture numérique, design), on sait que GIMP est pas mal utilisé par les designers de jeux indés, énormément dans l'astronomie aussi, pas mal de gens dans la création de cartes (encore plus depuis qu'on a ajouté la prise en charge des métadonnées GeoTIFF, ce qui simplifie l'usage de GIMP en soutien à des logiciels de cartographie; j'ai l'impression que maintenant pas mal dans cette communauté recommandent GIMP grâce à cela), en recherche ou médecine aussi (en histoire récente, je me souviens d'un rapport de gens qui fabriquaient du matériel médical qui traitait des images de taille genre 100k×100k — GIMP est très efficace sur les grandes images — et avaient besoin de la prises en charge dans GIMP de certaines capacités de TIFF — ce qui fut implémenté —; ou encore de quelqu'un sur un forum qui travaille en laboratoire sur la recherche de chromosomes et voulait passer à GIMP pour traiter de l'imagerie), en 3D (traitement de textures, etc. Dans les histoires dont je me souviens, on a eu un centre de formation en ligne qui nous a demandé d'implémenter une fonctionnalité que seul un logiciel propriétaire quelconque — dont je me souviens plus le nom — avait et qui permettait de traiter plusieurs types de textures représentant une même zone à la fois; ben maintenant y a 2 logiciels qui ont cette fonctionnalité: cet autre logiciel proprio et GIMP, en libre; ils ont ainsi pu utiliser GIMP pour une formation sur la photogrammétrie). Etc. Etc. Etc.
Enfin bon, on ne manque pas de rapports de bugs et de cas d'usage réels pour l'amélioration de GIMP. :-)
Je pense qu'une bonne partie de ceux qui critiquent n'utilisent simplement pas GIMP, voire de manière générale n'ont même pas vraiment l'usage de ce genre de logiciel (hormis pour une rotation et une découpe d'image une fois par mois, alors forcément GIMP, ça leur semble une usine à gaz inutilisable avec toutes ses fonctionnalités!).
Petite histoire vraie: depuis qu'on est sur le Microsoft Store, il m'arrive parfois de lire les commentaires des gens juste pour me faire du bien. En effet GIMP y a une super note (4.5/5 sur la base de plus de 8000 notes dont plus de 1000 avec commentaires en un an!) et il y a tellement de gens (la grosse majorité des commentaires du store) qui y disent des trucs gentils sur GIMP et sur le fait que ça les aide au quotidien et qu'il est super puissant/utilisable. 💌
Allez, pour le plaisir, petit florilège partiel sur uniquement les 5 derniers jours (je n'ai pas mis tous les commentaires positifs et il n'y avait que 2 commentaires négatifs dans cet intervalle temporel):
[Inde]
[États Unis]
[Pologne]
[Argentine]
[Équateur]
Alors forcément, quand on ne lit quasiment que ce genre de commentaires, ça redonne goût à ce qu'on fait!
Et c'est dans ce genre de cas que parfois je me rends compte que certaines personnes dans la communauté Linux sont juste méchants et ne se plaignent que pour le plaisir de se plaindre, et surtout le plus bruyamment possible. C'est quand même ironique que je doive lire les commentaires des Windowsiens pour voir à quel point GIMP est apprécié quand j'utilise moi-même Linux depuis une vingtaine d'années.
Parce que si je devais me limiter par exemple à Reddit ou HackerNews, la vision que j'aurais des avis sur notre logiciel serait bien plus triste. Surtout que quand on lit les "raisons" des gens qui se plaignent, on se rend souvent vite compte qu'une majorité de ceux qui critiquent n'utilisent simplement pas GIMP.
Enfin bon, j'ai appris à m'abstraire des commentaires lambda désobligeants sur les forums, lesquels donnent parfois, mais rarement, des critiques constructives et réellement utilisables pour améliorer le logiciel. Non parce que sinon, ça fait longtemps que je serais tombé en dépression et aurait abandonné. 😰
Allez pour finir sur une note positive, deux derniers commentaires du Microsoft Store, d'il y a 10 jours et 3 semaines:
[Allemagne]
[États Unis]
💌
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: UI
Posté par orfenor . Évalué à 3. Dernière modification le 27 juillet 2023 à 00:17.
Désolé je voulais dire qu'Aryom peut faire des retours très efficaces.
[^] # Re: UI
Posté par Jehan (site web personnel, Mastodon) . Évalué à 4.
Pas de prob. Je me devais juste de faire la remarque, mais ça arrive. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: UI
Posté par Psychofox (Mastodon) . Évalué à 9. Dernière modification le 27 juillet 2023 à 08:19.
Je ne crois pas que reddit et hn sont des représentatifs de la communauté linux. D'ailleurs je ne pense pas qu'il y a plus de linuxiens que de windowsiens ou macosiens qui intéragissent sur ces platformes.
Par contre oui, les gens y commentent sur des trucs qu'ils n'utilisent pas, pour des raisons qui sont souvent obsolètes depuis des décennies (parce qu'ils ont testé une fois en 2001), et réutilisent parfois des légendes urbaines, critiques infondées relayées de non utilisateur à non utilisateurs, pour justifier leur usage d'une autre logiciel.
Ce n'est d'ailleurs pas propre à Gimp. Dès qu'un logiciel est mentionné, tous ceux qui en utilisent un autre se sentent obligés de le descendre pour affirmer à quel point leur choix à eux est justifié et bon. Ça ressemble à une sorte de mécanisme de défense comme si proposer un logciel remettait leur sens de la prise de décision en cause.
Je suis aussi utilisateur de Gimp depuis plus de 2 décades, j'avoue que je suis toujours perplexe devant ces supposés manquemant en terme d'UX mais je ne sais pas si
Du reste en rédigeant le précédent commentaire, je suis allé voir du côté de photopea, un éditeur d'image proprio en ligne qui est souvent mentionné dans les nouvelles au sujet de Gimp sur HN, et supposé reprendre l'UX de photoshop le plus fidèlement possible (pas envie de souscrire une licence Adobe pour comparer). Ben je n'ai pas trouvé tant de grandes différences fondamentales entre photopea et Gimp en terme d'UI. Un ordre un peu différent des menus, un placement vertical des outils plutôt que dans une boîte unique et des paramètres qui apparaissent horizontalement au dessus de l'image. Je n'ai ni été dépaysé, ni impressionné, ni me suit dit c'était plus cohérent et utilisable. Idem pour Krita.
Bref bravo pour le travail de l'équipe de Gimp
[^] # Re: UI
Posté par arnaudus . Évalué à 3. Dernière modification le 21 août 2023 à 18:23.
Je pense qu'il est habituel de partir du principe qu'un logiciel muni d'une GUI, c'est comme un site web, ça ne nécessite pas de doc ou de tutoriel pour comprendre son fonctionnement, ce qui ne marche pas vraiment avec GIMP. Justement, GIMP pourrait aussi trouver son public auprès d'utilisateurs occasionnels, via une interface simplifiée par exemple. Ce n'est pas la direction qui est prise, et il n'y a rien de mal à ça, mais du coup il ne faut pas s'étonner que certains se plaignent de son interface (en tout cas, en tant qu'utilisateur occasionnel, je trouve son interface souvent très frustrante).
Exemple typique: j'ouvre une image avec Gimp pour trouver un exemple, bah je l'ai tout de suite: il n'y a pas de barres d'outils. J'ai dû les fermer en me gourant de fenêtre la dernière fois ou quelque chose comme ça. J'ai cliqué au pif dans Windows -> Toolbox et j'ai retrouvé une partie des trucs, mais franchement, je pense que personne ne veut ouvrir un logiciel et ne rien voir. Si moi je dois aller farfouiller pour même de faire quoi que ce soit, quelqu'un d'un peu moins habitué aux ordinateurs n'arrivera jamais à commencer.
Deuxième exemple: je veux rajouter du texte à mon image, je clique sur texte, je clique dans l'image, je tape mon texte. Je veux fermer le dialogue, je clique ailleurs dans l'image; ça crée une autre zone de texte. Je clique en dehors de l'image, ça crée une zone de texte en dehors de l'image. Ça, aucun logiciel ne le fait, c'est juste non-intuitif. Sous Powerpoint, LibreOffice, ou n'importe quel logiciel en fait, cliquer en dehors du menu fait disparaitre le menu. Bah là, non.
Troisième exemple: j'écris "Toto" en haut, j'écris "Tutu" en bas de l'image, je me dis "en fait, je vais supprimer "Toto", alors je clique sur la gomme, et paf, ça ne marche pas, parce que la sélection est autour de Tutu. Echap? Non. Clic droit? Non. On reprend l'outil de sélection, on sélectionne autour de "Tutu"? Non, il y a maintenant deux zones sélectionnées (wtf?). C'est hyper frustrant. Mon expérience avec GIMP, c'est de passer 80% du temps à essayer de comprendre pourquoi ça n'écrit pas sur le dessin, et d'écraser ma souris en grinçant "P***ain, mais écris!".
Évidemment, GIMP n'est pas buggué. Il a juste un comportement qui est hyper non-intuitif. Ça n'est même pas qu'il est mal conçu, c'est qu'il est juste trop "pensé", comme si c'était mal de faire comme les autres logiciels, comme s'il fallait en quelque sorte "payer" le droit d'utiliser les fonctions de base en pleurant des larmes de frustration.
C'est nettement plus facile à dire qu'à faire, mais les designers, normalement, ils prennent un échantillon des clients potentiels du logiciel, ils les mettent devant, et ils leur demandent de faire un tâche simple (passer la photo en noir et blanc, la tourner de 90°, etc). Ils prennent des notes sur ce que les gens font, et font évoluer le logiciel pour que ce que les gens font intuitivement fasse en fait ce que c'est sensé faire.
Encore une fois, l'argument du public visé, de l'originalité, de la dette technique, tout ça s'entend. Mais les réponses du style "je ne vois pas ce qui ne va pas dans l'interface avec Gimp", c'est quand même bizarre, parce qu'en tout cas pour moi ce qui ne va pas, ça me crève les yeux : le truc ne fait juste pas ce que tu lui demandes de faire, et les raisons pour lesquelles il ne le fait pas sont incompréhensibles. C'est une sorte de vi en mode graphique, en fait :-) J'utilise souvent vi et je m'en sors honorablement la plupart du temps, mais en effet, la complexité de son interface me semble quand même évidente.
[^] # Re: UI
Posté par Psychofox (Mastodon) . Évalué à 4.
Je n'ai jamais lu la doc de Gimp hein. Et tu n'as surement jamais utilisé photoshop ou aucun autre logiciel métier si tu penses que tu ne te retrouves jamais dans les situations mentionnée où tu ne comprends pas ce qu'il se passe. Même sur des trucs très très grand public comme OFfice, vas éditer un powerpoint ou un document word remplis de captures d'écrans réalisé par une autre personne, tu vas aussi rire un bon coup si tu crois qu'en quelques clics tout va s'aligner comme tu l'imaginais au début. C'est essentiellement une des tarres du concept WYSIWYG et la plupart des logiciels ont leurs souçis à ce niveau. Le truc c'est qu'à part de l'édition basique typique de ce que tu ferais avec imagemagick, c'est assez compliqué d'étiter des images en WYSIWYM, à part pour les générer via deep learning.
[^] # Re: UI
Posté par arnaudus . Évalué à 2.
20 ans de recherches Google peuvent facilement remplacer la doc, ça n'est pas un signe d'interface intuitive.
Un outil en ligne de commande, tu sais que tu vas devoir lire une doc pour comprendre comment il marche. Un logiciel muni d'une interface graphique, tu peux légitimement t'attendre à pouvoir l'utiliser sans aller suivre une formation. Ça marche aussi pour les jeux par exemple; souvent, les jeux commerciaux sont conçus pour être utilisables directement, ce qui n'est pas le cas de tous les jeux non-commerciaux.
Oui, mais ça c'est lié à la mauvaise utilisation des outils. C'est une question de philosophie, soit le logiciel t'interdit de faire ce genre de choses, mais du coup il est limitant, soit il l'autorise, et du coup il permet de produire des fichiers irrécupérables. Avec Gimp tu peux aussi encoder une image avec un pixel par layer, ça ne va pas être facilement manipulable non plus.
Tu veux dire que tu penses qu'il n'est pas possible de créer un document Latex irrécupérable? :-)
GIMP est scriptable…
Une interface AI du type "chatbot" me semblerait tout à fait faisable, avec des séries de commandes séquentielles ("éclaicis un peu l'image", "diminue le contraste à l'arrière plan", "retire les fils électriques", "non, tu as retiré les cheveux des personnes, seulement les fils électriques", etc.).
[^] # Re: UI
Posté par Psychofox (Mastodon) . Évalué à 3.
oui je sais mais tu vas rarement utiliser les fonctionnalité de scripting pour dessiner, faire des sélections manuelles, etc.
[^] # Re: UI
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Sérieux ? Faut qu'un logiciel métier, pour ne pas te paraître "buggé" ou te paraître intuitif, ne se comporte pas du tout comme il faudrait pour les gens du métier mais plutôt un truc qui à des années lumières de là ? Tu penses vraiment que les designers sont tellement con-ne-s que leur profession se refuse à utiliser "Powerpoint, LibreOffice, ou n'importe quel logiciel en fait" ?
Moi je vois bien ce qui ne va pas dans ce commentaire : un soit-disant utilisateur occasionnel (pour moi on en est loin quand il s'agit de lancer une fois en passant ms paint) qui étale sa croyance comme vérité absolue. Ça crève les yeux tu expliqueras aux pilotes d'avions que non mais leur truc ne fait pas l'affaire parce-que ça ne se comporte pas comme ton four et que c'est un dysfonctionnement évident.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Livre
Posté par alberic89 🐧 . Évalué à 3.
Quelques livres français qui ne sont pas référencés :
https://www.editions-eni.fr/livre/gimp-2-10-9782409016233
https://www.fnac.com/a4205493/Dimitri-Robert-Gimp-2-8-debuter-en-retouche-photo-et-graphisme-libre
https://www.fnac.com/a4243742/Julien-Pons-Gimp-2-8
https://www.fnac.com/a10634027/Raymond-Ostertag-Cahier-Gimp-2-10
https://www.fnac.com/a4056701/Mehdi-Kabab-Gimp-2-8
https://www.fnac.com/a3330084/Raymond-Ostertag-Gimp-2-8-special-debutants-avec-cd-rom
Et plus généralement :
https://www.fnac.com/n232437/Livres-Informatique/Logiciels-Graphisme-CAO/Gimp
Ils ne sont pas tous tout jeunes, mais c'est déjà plus récent que ce qu'on a actuellement dans la section des livres français.
Si quelqu'un pourrait les ajouter, je n'arrive pas à créer un compte GitLab GNOME (adresse mail refusée).
Il y a 10 sortes de gens dans le monde – ceux qui comprennent le ternaire, ceux qui ne le comprennent pas et ceux qui le confondent avec le binaire.
# Intégration de DragGAN ?
Posté par phroy (site web personnel) . Évalué à 1.
Est-ce que vous savez si il y a un/des projets d'intégration d'outils génératifs du type DragGAN?
# Bravo et merci
Posté par Phelibre (site web personnel) . Évalué à 7.
Merci pour l'article et bravo pour ce travail de développement qui a commencé le siècle dernier (j'ai connu The Gimp en 98) ! Il me reste à faire un don :)
[^] # Re: Bravo et merci
Posté par antistress (site web personnel) . Évalué à 10. Dernière modification le 26 juillet 2023 à 10:34.
Wow, je vois, au delà de ce que vous livrez micro version après micro version et ce qui est d'ores et déjà en préparation pour la prochaine version majeure, le nb de contributeurices fleurir, la nouvelle dynamique de release rapide, le travail de communication… Franchement Jehan tu peux être fier de la dynamique que tu as créée et de l'animation du projet que tu impulses (en plus de tout le code que tu fournis) ! Bravo à toi :)
# Roadmap
Posté par antistress (site web personnel) . Évalué à 4. Dernière modification le 26 juillet 2023 à 10:32.
Je mets ici en exergue ce lien "caché" dans la dépêche qui répondra peut être à certaines questions :
# Améliorations pour remplir/tracer la sélection/le chemin
Posté par antistress (site web personnel) . Évalué à 4.
# Pourquoi attendre pour publier une version 3.0 ?
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Bonjour,
Depuis plusieurs mois (années ?), je lis vos comptes rendu des nouvelles fonctionnalités, et elles me semblent très intéressantes (bien que je ne fasse plus de photo). Pourquoi attendre pour sortir une version 3.0 finale ? Pour moi le risque d'attendre trop longtemps est de démotiver les développeurs de n'avoir rien de montrable "officiellement", et de démotiver les utilisateurs attendant trop longtemps les nouvelles fonctionnalités et commençant à aller voir la concurrence (!).
Merci pour tous ces chouettes articles en tout cas. Et GIMP est un logiciel génial, belle vitrine du logiciel libre !
[^] # Re: Pourquoi attendre pour publier une version 3.0 ?
Posté par antistress (site web personnel) . Évalué à 7. Dernière modification le 27 juillet 2023 à 15:08.
Parce que c'est comme la pizza, t'attends qu'elle soit cuite.
[^] # Re: Pourquoi attendre pour publier une version 3.0 ?
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Déjà parce qu'on était dans le modèle ancien de "release when it's ready", qui explique que la sortie de GIMP 2.8 a aussi mis 4 ans (2008 à 2012), 2.10 a mis 6 ans (2012 à 2018) et 3.0 aura vraisemblablement mis entre 5 et 6 ans (on a démarré en 2018).
Comme les gens le savent, on est en train de changer ce modèle (bon on sort encore les choses "quand elles sont prêtes" mais tout la subtilité est d'arriver à définir différemment "ce qui doit être prêt"), d'ailleurs sur une impulsion de notre part, puisque c'est un changement que j'ai proposé lors du Libre Graphics Meeting de 2014. C'est ainsi que depuis GIMP 2.10.0, on applique cette nouvelle politique de sortie: on sort désormais de nouvelles fonctionnalités même lors des sorties micro maintenant! Tout ce qui est suffisamment aisément backportables sort dans les versions 2.10.x. Je suggère donc de jeter un œil sur le tag "GIMP" sur Linuxfr et de lire les articles de sortie des versions stables pour se rendre compte qu'il y a des nouveautés à chaque fois (et pas juste des corrections de bug).
Donc si ce que tu dis était vrai avant 2018, ce n'est plus le cas depuis (puisque maintenant les développeurs attendent juste quelques mois pour voir leur code utilisé et les utilisateurs pour l'utiliser).
Ensuite comme tout, on peut faire mieux. Mais cela demande rigueur et organisation. Et surtout, cela prend du temps, des années même. On ne change pas une organisation de 28 ans en quelques mois (c'est le meilleur moyen de tout pêter, certains l'apprennent à leurs dépends, par exemple des milliardaires qui s'amusent à acheter des boîtes et les font quasi couler en quelques mois en pensant être des révolutionnaires! 🙄).
Et donc maintenant après la première étape de 2018 avec GIMP 2.10, on passera à une seconde étape avec GIMP 3.0. Je l'explique d'ailleurs dans mon rapport 2022 de janvier 2023 (qui n'a pas été traduit sur Linuxfr):
En gros, on arrête de faire de grosses cibles gigantesques. J'ai aussi entièrement réorganisé notre roadmap post-3.0 non plus par versions mais en sous-roadmaps par catégorie de fonctionnalités dont les éléments peuvent être implémentées dans n'importe quelle version. C'est important puisque ça signifie que nous ne sommes plus contraints à de grosses listes de fonctionnalités. Nous avons maintenant un ensemble de directions globales vers lesquelles nous nous dirigeons (notre "vision" pour le futur de GIMP, en gros), c'est tout.
Donc c'est bien ce qu'on fait, on a même déjà commencé depuis plusieurs années; ça prend juste du temps pour faire encore mieux.
Il y a un autre point important: une sortie de version est un évènement très lourd. On rappelle que GIMP est téléchargé des dizaines de milliers de fois par jour. On ne fait pas une nouvelle version comme on va au marché. C'est lourd en responsabilité, mais aussi techniquement, avec du code et des builds à tester à répétition, un flatpak pour x86_64 et ARM64, deux paquets macOS (aussi pour ces deux architectures) et un installeur Windows (qui marche pour x86 32 et 64-bit et possiblement aussi un installeur ARM bientôt), puis une dépêche qui me prend des jours à écrire, etc. Une sortie bien faite en gros, ça peut être des semaines de travail juste pour tous les aspects hors-code (donc tout ce temps en moins pour coder! Plus on fait de sorties, moins vite on peut améliorer GIMP; il faut donc trouver le juste milieu). Imagine une sortie d'une version majeure maintenant, surtout qu'on n'en a pas faite depuis 20 ans.
Ça fait des années que je travaille sur tout l'aspect technique (hors code de GIMP même, j'entends) pour préparer cette sortie. En cumulé, j'ai probablement passé des semaines ou des mois à créer et améliorer nos scripts d'intégration continu, qui permettent aussi d'automatiser le plus possible nos créations de binaires de sortie (le flatpak n'existait pas à l'époque mais les tarballs de source autant que les installeurs Windows ou DMG macOS, avant moi, c'était des binaires opaques que des contributeurs faisaient sur leur machine perso puis envoyaient sur les serveurs; rendre le tout plus transparent fut un de mes gros chantiers et ce fut loin d'être facile avec certains contributeurs — notamment je me souviens d'un qui n'est plus là et qui n'a pas apprécié les premières tentatives d'automatiser la création des paquets macOS). Sans compter tout le travail fait pour améliorer notre checklist de procédure de sortie. Cela existait déjà avant, comme un fichier texte dans le dépôt suivi par juste le mainteneur. J'essaie maintenant d'intégrer davantage les testeurs, les empaqueteurs, etc. En gros d'avoir une sortie avec le moins de heurts possibles, tout en étant aussi plus robuste.
Maintenant spécifiquement pour GIMP 3.0, je pense pouvoir expliquer la durée par quelques points:
On essaie d'éviter ça (même s'il faut "jamais dire jamais", comme on dit!). On se permet un cassage avec GIMP 3 en 20 ans (et même là je me suis plus d'une fois demandé si on aurait pas pu faire mieux), et j'espère qu'on va pas en avoir beaucoup plus. Donc si on n'a que cette chance pour casser l'API, autant le faire bien.
De manière générale, nous sommes un projet un peu à l'ancienne dans les philosophies de développement, mais aussi dans la définition de ce qu'est du bon développement. Notamment vous remarquerez que les mots "stable" ou "stabilité" sont répétés beaucoup dans ce seul commentaire. C'est en effet un concept important pour nous sur plein de choses. J'ai aussi l'impression que les mainteneurs de GIMP sont une longue lignée de perfectionnistes. Saviez-vous qu'on est censé pouvoir ouvrir un fichier XCF de 1997 avec son rendu de l'époque? Nous en sommes à la version 18 de XCF avec énormément de nouveautés dans le format, mais on peut encore ouvrir les fichiers d'il y a 26 ans! Peu de projets (même libres! Quant aux logiciels propriétaires, n'en parlons même pas tellement ils ont de casseroles sur ce sujet) peuvent s'enorgueillir de cela, et même tout simplement de placer ce niveau de rétrocompatibilité dans leurs checklists lors des changements de format.
Et donc voilà, tout cela explique pourquoi cela prend du temps. Ensuite on peut tout de même améliorer la fréquence des sorties sans pour autant perdre en qualité, mais c'est alors surtout une réorganisation en profondeur qui ne peut que prendre encore plus de temps si on ne veut pas tout casser et si on veut travailler en bonne entente en communauté. Et c'est bien ce que nous faisons depuis plusieurs années.
Merci! 😄 (et merci à Matthieu pour sa traduction!)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Pourquoi attendre pour publier une version 3.0 ?
Posté par antistress (site web personnel) . Évalué à 4. Dernière modification le 30 juillet 2023 à 18:42.
Intéressant. Je vois souvent effectivement des devs de toolkit faire joujou avec des logiciels très simples, ça créé forcément un biais si c'est général
[^] # Re: Pourquoi attendre pour publier une version 3.0 ?
Posté par EmmanuelP . Évalué à 2.
C'est pas ça le problème. Penser qu'ils ne sont pas au courant de la difficulté de migration est une erreur. Comme pour GIMP, le nombre de développeurs bossant sur GLib/GTK est très réduit. Ils n'ont pas les ressources pour à la fois maintenir les anciennes API et développer de nouvelles plus efficaces et pratiques, ou qui sont l'occasion de faire un ménage de fond dans le code et sortir d'impasses techniques. Alors ça passe par la suppression, après un certain temps (normalement au passage de la version majeure suivante), des anciennes API remplacées par les nouvelles. Ne pas le faire, c'est prendre le risque inévitable de figer GTK et qu'il devienne de moins en moins pertinent.
[^] # Re: Pourquoi attendre pour publier une version 3.0 ?
Posté par antistress (site web personnel) . Évalué à 3.
OK merci
(modulo le fait que les devs de Gimp y parviennent)
[^] # Re: Pourquoi attendre pour publier une version 3.0 ?
Posté par bayo . Évalué à 4.
Ahahah, bonne blague.
[^] # Re: Pourquoi attendre pour publier une version 3.0 ?
Posté par orfenor . Évalué à 4.
Et c'est remarquable ! Dieu sait si 26 ans ça passe vite. Si l'envie ou le besoin me prend un jour de réouvrir mes premiers travaux, je vous bénirais. Tandis que mes trucs avec Photoshop 2.5 nécessiteront un jeu de machines virtuelles et de réinstallation tellement long que je me contenterai du souvenir.
# Gimp's TK
Posté par jyes . Évalué à 10.
C’est tristement amusant de relever qu’au départ GTK est le sigle pour “Gimp’s Tool Kit”, une bibliothèque reprenant les widgets graphiques dévéloppés pour Gimp et les mutualisant pour être utilisés dans d’autres applications. Avec les évolutions de GTK et ses simplifications, c’est avec une pointe d’amertume que je lis que vous avez dû réintroduire des GimpAction, GimpToolbar et GimpMenuBar entre autres widgets pour compléter leurs pendants GTK* qui ont été trop simplifiés. À quand une mutualisation de ces widgets dans un nouveau toolkit de Gimp partagé afin que d’autres applications puissent s’en servir aussi? Un GTK-ng…
Autant, je pense que simplifier un toolkit ça a du sens, surtout pour un truc durable comme GTK, autant si le projet dont est issu GTK en arrive lui-même redévelopper un pseudo-toolkit par dessus GTK, c’est que GTK a sûrement taillé un peu trop dans le code.
# les algos de traitement
Posté par orfenor . Évalué à 2.
Pendant que je teste des outils plus légers que Gimp (Photoflare par exemple), je me demande si la qualité des algorithmes est la même ? On se doute qu'un outil pour les professionnels doit avoir les meilleurs rendus possibles, tandis qu'un petit éditeur d'image peut simplifier un peu les choses, mais jusqu'à quel point ? Alors qu'un test rapide de retouches simples avec Photoflare me laisse dubitatif, je me demande s'il existe des outils légers de retouche d'image réutilisant des algos «pointus» ?
Et question secondaire, d'où viennent ces algos ? Comment les connaissez-vous ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.