Sommaire
Corrections de bogues et activité de développement
Entre GIMP 2.10.0 et 2.10.2, en moins d’un mois, 292 commits se sont produits (soit une moyenne de 12 commits par jour, dont plus de 60 % par trois développeurs) et 44 bogues corrigés.
Il s’agit donc d’un développement très actif, bien que limité par le faible nombre de développeurs.
Nouvelles fonctionnalités
Prise en charge du format HEIF
GIMP 2.10.2 propose la prise en charge du format d’image HEIF, en lecture et écriture, contribué par Dirk Farin.
De nouveaux filtres
Deux nouveaux filtres ont aussi été ajoutés :
Quelques améliorations notables
Amélioration de performances (calcul d’histogrammes)
Les histogrammes sont désormais calculés dans des fils d’exécution séparés, libérant ainsi le fil d’exécution principal et améliorant encore plus la réactivité de l’interface graphique. Cela fait suite aux diverses améliorations des performances de GIMP depuis la version 2.10.0.
Greffon de capture d’écran amélioré pour Windows
Sur les systèmes Microsoft, la capture d’écran par fenêtre ne fonctionnait pas si la fenêtre était cachée ou hors du champ du bureau. Cela est désormais réparé.
Coopérer avec les tiers
GIMP est un logiciel très répandu et, par conséquent, nous avons beaucoup d’interaction avec des projets tiers. Trouver une logique de coopération est donc important.
Rapports de bogues et paquets tiers
L’une des problématiques est de permettre aux empaqueteurs de gérer leurs utilisateurs. En effet, GIMP est rapidement empaqueté par de nombreuses personnes et entités. Parfois certains font même des binaires plus rapidement que le projet GIMP (notamment pour Windows et macOS).
Malheureusement, cela signifie que nous recevons aussi beaucoup de rapports de bogues pour des problèmes spécifiques à des paquets tiers, par exemple lorsqu’ils ont modifié le code source, ou bien ont rajouté des greffons tiers ou au contraire retiré des fonctionnalités, ont des problèmes de dépendances, de compilation, etc.
Recevoir des dizaines de rapports de bogues pour ces divers paquets (par exemple, pour une version PortableApp, un paquet Arch Linux, etc.) et devoir les gérer, faire du débogage, pour finalement comprendre que le problème est dans le paquet et demander à tous les utilisateurs de rapporter le problème à l’empaqueteur, gérer les duplicatas, etc., nous prend énormément de temps que l’on préférerait passer à améliorer GIMP.
Dans tous les cas, il est souvent préférable de rapporter les bogues auprès de l’empaqueteur, qui peut effectuer un premier tri avant éventuellement de nous rapporter le bogue (une seule fois) s’il estime qu’il se trouve dans le code source, après avoir testé.
C’est pourquoi j’ai rajouté l’option de compilation --with-bug-report-url permettant à un empaqueteur de préciser sa propre adresse d’outil de suivi, qui sera ouverte notamment en cas de plantage de GIMP.
Lecture de XCF par programmes tiers
Le format XCF n’est pas un format d’échange (contrairement par exemple au format OpenRaster). Son but est d’être le plus proche possible du fonctionnement interne de GIMP, en suivant les fonctionnalités.
Néanmoins il est normal que d’autres logiciels souhaitent tout de même pouvoir lire ces fichiers. Dès 2006, un contributeur (Henning Makholm) avait documenté le format XCF et cette documentation avait finalement été intégrée dans notre dépôt de source. Nous avons reçu quelques demandes répétées de mettre à jour cette documentation. J’ai donc pris une journée et demi pour la mettre à jour avec les changements du format depuis GIMP 2.8 (si des imprécisions ou des erreurs subsistent, chacun est le bienvenu pour déposer un rapport de bogue).
Les nombreux logiciels souhaitant prendre en charge XCF sont donc invités à se mettre à jour. Notez que la version git log peut être plus intéressante pour distinguer plus aisément le différentiel entre GIMP 2.8 et GIMP 2.10.
Autres évolutions
Flatpak
Nous rappelons que GIMP est désormais disponible en version Flatpak officielle (maintenue par l’équipe de GIMP, en particulier par moi‐même). Encore une fois, cette version binaire est même sortie la première, avant un installeur Windows ou un paquet macOS !
Néanmoins, nous avons aussi eu plusieurs remarques concernant cette version et ses limitations (dues en partie au modèle de sandbox, la jeunesse de la technologie Flatpak et la non‐adaptation de GIMP à certains aspects du modèle).
Je souhaite donc rappeler que (contrairement aux plates‐formes Windows et macOS), le paquet de votre distribution GNU/Linux est encore la méthode officiellement recommandée par le projet GIMP ! Cela était déjà clairement noté sur notre page de téléchargement, mais pas assez mis en avant. J’ai donc un peu remis en page le texte sur gimp.org/download pour que cela soit plus clair :
Bien sûr, cela pourra changer, mais pour l’instant certaines fonctionnalités sont perdues, comme l’utilisation de darktable et RawTherapeee comme greffons pour ouvrir les fichier RAW (ces logiciels étant recherchés par le $PATH, et n’étant pas accessibles dans un environnement bac à sable), ou encore le contrôle de GIMP par des périphériques MIDI, etc.
Les avantages de Flatpak à ce jour sont : la mise à jour au plus tôt après une sortie de GIMP (alors que les distributions peuvent avoir plusieurs mois de retard, voire années pour des LTS), un système auto‐contenu pouvant être lancé depuis n’importe quelle distribution, et une version disponible et utilisable directement pour quatre architectures, notamment ARM et AArch64 (donc, a priori, installer GIMP sur un Raspberry Pi devrait être possible en un clic ou une commande, mais je n’ai jamais testé !).
Source et suivi de bogues migrés sur le GitLab de GNOME
Une autre évolution majeure dans notre processus de travail est que nous suivons GNOME dans leur migration vers le logiciel Gitlab.
Cela fait suite à un projet de migration de longue haleine, de la part de nos amis de chez GNOME, et qui touche à sa fin.
Le déménagement de GIMP est effectif depuis jeudi 24 mai 2018 (le source est déjà présent et les rapports de bogues en cours de migration à l’heure d’écriture de ces lignes). Vous pouvez désormais obtenir le code source de GIMP et créer de nouveaux rapports de bogues à cette adresse : https://gitlab.gnome.org/GNOME/gimp.
Nous noterons que GNOME effectue cette migration en collaboration avec l’entreprise GitLab (de ce que j’en ai compris), qui effectue des modifications dans son logiciel pour les besoins des projets GNOME et amis.
Notamment, il est à noter que nous refusons les « commits de fusion » chez GIMP (même si parfois, certains apparaissent subrepticement), pour raison de lisibilité de l’historique, ce qui est un gros problème avec le processus de « demande d’intégration / demande de fusion » (Pull Request / Merge Request) propre à ce type de plate‐forme, et était donc un des freins de nombreux projets. Cela fait donc partie des changements fait par GitLab pour accueillir certains projets qui ont la possibilité de désactiver de tels commits non désirés (ce que GIMP a donc fait).
Notons que tout est encore un peu flou, et que je ne suis pas certain de beaucoup de détails, ce qui est normal, car le changement est frais de quelques heures ! Nous verrons donc dans les jours qui suivent.
En tout cas, je sais que c’est un appel d’air frais que beaucoup trouveront bienvenu, car certains semblaient redouter le vieillissant Bugzilla. Je souhaiterais cependant prendre un peu le contrepied de cette opinion populaire en remerciant les nombreux développeurs de Bugzilla, qui nous ont fourni un excellent logiciel pendant de nombreuses années — certes, avec ses imperfections, mais quel logiciel n’en a pas ? Surtout un logiciel né en 1998, soit à peine moins vieux que GIMP !
Merci Bugzilla ! Tu as fait du super boulot et on te souhaite de continuer à aider plein d’autres projets pendant longtemps !
GIMP 3 : le voyage a commencé
Nous avons commencé à travailler sur GIMP 3, qui est le portage de GIMP en GTK+ 3, et c’est extrêmement excitant ! En fait, le jour de la sortie de GIMP 2.10.0, le travail sur GIMP 3 a commencé de manière poussée (plus de 200 commits en un mois, en plus donc des commits sur la branche stable, dont les statistiques sont notées plus haut). L’une des tâches principales du portage étant de nettoyer le source de bouts de code ou de données obsolètes rendus inutiles par GTK+ 3. En un mois, cette branche a ainsi connu 9 805 lignes de codes insérées pour 921 630 lignes supprimées (NdM.: 50k de code et ~870k de SVG) !
Certains des développeurs principaux de GIMP représentés par Aryeom
Notons aussi que le jour de la sortie de GIMP 2.10.2, le portage vers GTK+ 3 est devenu officiellement notre branche principale (master), le signe qu’il s’agit maintenant de notre nouvelle priorité numéro 1.
N. D. M. : Jehan est non seulement un fidèle écrivain sur LinuxFr.org, l’un des principaux développeurs de GIMP, mais aussi et surtout l’auteur avec Aryeom du film d’animation ZeMarmot dont on a beaucoup parlé sur LinuxFr.org et qui a toujours besoin d’aide.
Filtre Spherize sur une image CC By-SA par 
Filtre Recursive Transform sur une 
