Nous avons sorti GIMP 2.10.0-RC1 il y a déjà presque 3 semaines (et sommes même sur le point de sortir une RC2)! Mais c’est seulement maintenant que nous faisons notre petit compte-rendu habituel de contributeurs, en français (celui en anglais a été fait la semaine dernière, ce qui était déjà tard). Notre excuse étant bien entendu le fait que le développement de GIMP et la production de ZeMarmot nous prend le plus gros de notre temps; j’espère que vous considérerez cette excuse aussi valide que nous. 😉

Quoiqu’il en soit, ceci fut notre première Release Candidate de GIMP 2.10.0, c’est donc un énorme évènement (une Release Candidate, c’est une version presque finale, un peu entre une version de développement et une version stable)! Eh oui, 6 ans déjà que vous l’attendez, et l’attente touche à sa fin…

Quelle fut la partication de ZeMarmot?

C’est d’autant plus une sortie excitante pour nous que pour la première fois, je fus le contributeur majeur, avec 270 commits sur les 784 faits entre 2.9.8 et 2.10.0-RC1. C’est donc plus du tiers des modifications et corrections de bugs sur les 4 derniers mois! D’autres participants du projet ZeMarmot ont eux-même quelques commits, notamment Aryeom, notre réalisatrice, qui a contribué 2 icônes manquantes (pour se changer les idées entre ses séances d’animation de marmottes, image par image), ainsi que Lionel (un des membres du CA de l’association LILA qui gère le projet) qui a travaillé sur l’amélioration de la prise en charge de l’unité de mesure “pouce”.

On le voit, à chaque sortie, ZeMarmot est un acteur de plus en plus majeur du développement de GIMP. Il n’y a pas à dire, nous en sommes fier. Normalement après chaque sortie, je liste en détail mes contributions, mais il y en a tellement que j’ai décidé de désormais limiter aux quelques contributions plus marquantes:

• Amélioration du debuggage avec une boîte de dialogue récupérant des données et traces d’exécution. J’en ai déjà parlé (en anglais seulement).
• Sauvegarde automatiques d’images juste avant un crash! Oui vous ne rêvez pas! Alors je sais… GIMP est très stable. On a donc eu quelques remarques à ce sujet nous disant que de toutes façons, GIMP ne plante jamais (et on est fier de lire ce type de remarques car on a beaucoup travaillé pour en arriver à cette stabilité qui n’était absolument pas un acquis quand j’ai commencé à contribuer, il y a quelques années; c’est même l’une des raisons pour laquelle j’ai fait mes premiers patchs). Mais cela reste du logiciel, et dans le logiciel, tout est possible! Je développe celui-ci, et suis pourtant le premier à vous l’affirmer: non, GIMP n’est pas parfait! Il est très stable, mais les plantages peuvent arriver. Pire! C’est sûr, un jour, il vous plantera à la figure, si vous l’utilisez beaucoup! Et ce sera le jour où vous vous y attendrez le moins (loi de Murphy). La différence, c’est que maintenant GIMP sera prêt!
  Bon soyons précis, ce n’est pas non plus du “sauvetage” à 100%. Par nature, un crash est un état d’instabilité extrême d’un processus. On peut essayer de préserver des données, mais même cela peut échouer. Par contre souvent cela réussira. Et c’est seulement ce jour qui importera: celui où vos heures de travail auront été sauvées par ce petit bout de code. 😀
  
• La pipette à couleur prend maintenant en compte la gestion des couleurs de votre moniteur sur macOS.
• J’ai implémenté la capture d’écran avec l’API générique Freedesktop.  Sur les plateformes GNU/Linux, à terme, c’est censé remplacer les APIs spécifiques des environnements de bureaux. Néanmoins les implémentations GNOME/KDE gardent tout de même la priorité à ce jour jusqu’à ce que les implémentations Freedesktop soient plus complètes (et ainsi éviter des pertes de fonctionnalités).
• J’ai ajouté de nouvelles configuration des préférences pour l’export de métadonnées, et fait en sorte que tous nos plug-ins d’export respectent ces préférences (notamment en rajoutant de nouvelles APIs pour les développeurs de plug-ins: gimp_export_exif(),  gimp_export_xmp() et gimp_export_iptc()). C’est un sujet sensible car les métadonnées de fichiers peuvent contenir des données sensibles (votre nom souvent déjà, souvent le nom de votre entreprise voire votre adresse email, parfois même des coordonnées GPS que les appareils modernes ajoutent automatiquement, etc.) et clairement certaines personnes peuvent préférer ne pas avoir à gérer et filtrer manuellement ces données et simplement demander à ne pas les exporter par défaut.
• Diverses nouvelles APIs pour les développeurs de plug-in:
  • gimp_get_pdb_status() retourne le statut du dernier appel PDB. Cela permet à un plug-in qui dépend d’autres plug-ins d’en savoir plus sur les raisons de retour. Par exemple si une procédure est stoppée intéractivement, cela ne doit pas être considéré comme une erreur, mais plutôt comme une interruption manuelle.
  • gimp_stack_trace_available(), gimp_stack_trace_print() et gimp_stack_trace_query() pour aider au débuggage de plug-ins.
  • gimp_context_get_distance_metric() et gimp_context_set_distance_metric() pour le choix de métrique de distance utilisé par gimp_edit_blend() (et à usage futur).
• Amélioration de l’API gimp_edit_blend() qui se base maintenant sur l’opération “gegl:distance-transform“, ce qui rend la procédure bien plus rapide.
• Amélioration du traitement d’image splash avec du redimensionnement pour apparaître avec une taille raisonnable sur toute dimension d’écran.
• Des vulnérabilités furent reportés fin 2017, donc j’ai corrigé CVE-2017-17784, CVE-2017-17786, CVE-2017-17787 et CVE-2017-17789.

Au milieu de tout cela, j’ai aussi déjà annoncé le nouveau paquet mypaint-brushes.
Enfin il y a toutes ces autres mini-fonctionnalités mais surtout les nombreux bugs corrigés. En fait je ne crois pas que j’aurais pu corriger aussi facilement autant de bugs sans notre nouveau système de débug. Donc j’en suis particulièrement content. Je sais que certains ne considèrent pas cela si important (ce n’est pas une vraie fonctionnalité, pour du dessin ou de l’édition d’image ou autre). Je le sais, puisque j’ai lu sur un forum une remarque se plaignant que la news sur gimp.org mette surtout en avance des fonctionnalités de debug, comme si cela ne les valait pas. Pourtant c’est une des contributions dont je suis le plus fier. Je l’ai expérimentée ces derniers mois, et très clairement, cela nous a aidé énormément à débugguer plein de problème sans même avoir eu à demander aux gens de faire des actions ésotériques (telles que “pourriez-vous lancer GIMP dans un débuggueur?” – “Un quoi?”).
En outre je ne le rappellerai jamais assez, mais pour moi la stabilité et fiabilité d’un logiciel est l’une des bases qualitatives. Cette fonctionnalité va clairement dans ce sens.

Quoiqu’il en soit, je l’avais déjà dit: la correction de bug et stabilité sont mes buts personnels pour la 2.10. Comme vous le voyez, ce n’étaient pas des paroles en l’air. 🙂

Tutorer un étudiant pour coder dans GIMP

Parmi les autres nouvelles sympas, un étudiant, Darshan Kadu, nous a approché comme stagiaire FSF. Je lui ai proposé de continuer le portage de notre prise en charge du format JPEG2000  (passant d’une implémentation basée sur Jasper vers OpenJPEG, puisque la première bibliothèque est déprécié). J’agis donc comme tuteur. Ce n’est pas ma première fois à travailler avec des étudiants universitaires. J’ai déjà donné quelques cours dans une université parisienne l’an dernier, et franchement j’aime beaucoup ces échanges (que ce soit avec un seul stagiaire ou une classe entière).

Cela a relancé les discussions sur GSoC et si on souhaitait à nouveau tenter d’y participer (pour mémoire, le projet GIMP y a participé plusieurs années mais a ensuite arrêté; en fait il me semble que le dernier GSoC du projet fut l’année où j’ai commencé à faire mes premiers patchs sur GIMP, je n’ai donc jamais eu l’opportunité d’y participer en tant que tuteur). Quelques personnes proposaient d’avoir des stagiaires pour travailler sur toute sorte de fonctionnalités majeures dans le cœur de GIMP. Je voudrais commenter ce souhait.
Personnellement cela m’intéresse de participer car j’aime accompagner des étudiants dans le monde du développement professionnel. Si au passage, on peut avoir quelques patchs cools, c’est génial. Mais je pense qu’un tel évènement ne doit pas être utilisé juste pour avoir du “bon code pas cher”. Déjà car j’ai toujours détesté l’exploitation de stagiaires mal payés (bon en l’occurrence, avec GSoC, ils ont clairement une paie raisonnable). Ensuite simplement pour une raison qualitative: je pense que tout projet qui se repose principalement sur ce type de contribution ne peut obtenir que du code peu maintenable et de piètre qualité.

C’est simple: quelque soit votre métier, imaginez vous quand vous étiez étudiant. Maintenant demandez vous ce qu’il se passerait si on lâchait le “vous étudiant” à votre poste actuel (auquel vous êtes arrivé après des années à apprendre le métier, à faire des projets, avec des succès et des erreurs…). Pensez-vous vraiment que vous auriez révolutionné votre métier? J’espère que vous répondrez non, sinon c’est un peu triste que vous considériez ne pas avoir évolué posivitement depuis votre vie étudiante! ;p

Donc oui, GSoC comme tout stage, est une opportunité sympa pour travailler avec des jeunes esprits vifs et avec des idées neuves. Mais cela ne doit pas être pris comme une sorte de solution magique pour obtenir du code pas cher, rapide et bon. J’ai l’impression que beaucoup de gens voient cela ainsi malheureusement.
Bon on verra l’an prochain si on décide finalement d’y revenir (cette année encore, on ne s’est pas inscrit), mais je souhaitais donner un peu mon avis à ce sujet puisqu’il est dans l’air.

Release Candidate? Sortie de 2.10 bientôt?

Clairement nous travaillons dur ces derniers temps. Nous sommes même passé sous les 10 bugs bloquants il y a quelques jours (mais cela oscille beaucoup, et à l’heure d’écriture, on est de retour à 10 bugs)!

Nous avons tout de même dû discuter un peu s’il fallait vraiment nommer cette sortie une RC. En effet de manière stricte, ce ne devrait pas être un “candidat pour une sortie (stable)”. Cependant nous sommes un peu fatigué de trainer des pieds (depuis 6 ans!). GIMP 2.10 ne sera pas parfaite. Aucune sortie de logiciel ne sera jamais parfaite. C’est un fait! Mais GIMP 2.10 sera déjà vraiment méga cool, même s’il devait sortir dans l’état actuel. C’est pourquoi on s’est dit qu’on devait un peu pousser dans le bon sens. Faire une “Release Candidate” est donc une sortie psychologiquement forte pour se dire “maintenant faut qu’on pousse vers la sortie”. Et c’est donc exactement ce que l’on fait. 🙂
Attendez vous donc à voir la 2.10 très bientôt, sauf si vraiment on découvre un problème très grave que nous n’aurions pas repéré jusque là (on touche du bois!).

Amusez vous bien avec GIMP 2.10 RC1, tout le monde! Et surtout, testez, testez, testez! Et envoyez des rapports de bugs si vous trouvez quelque chose qui ne va pas! 😀

 

Rappel: vous pouvez financer mon travail sur du
Logiciel Libre sur Liberapay, Patreon ou Tipeee
à travers le projet ZeMarmot.