Journal Les dernières News de ZeMarmot

Sommaire

• • Du code
    • Système de debug
    • Sauvegarde lors de crashs
    • Plus de journaux sur des sujets divers
  • De la maintenance
  • De la collaboration
  • Un stagiaire FSF
  • Et des images!
    • Une animatrice en live
    • D'autres projets à côté
    • Geek Faëries on the web
  • Et voilà!

Depuis la dernière dépêche, le projet ZeMarmot continue son bonhomme de chemin.

Du code

Ce début d'année 2018 est particulièrement dense niveau code, puisque j'ai déjà fait 211 commits depuis la sortie de GIMP 2.9.8, le 12 novembre 2017, soit 34% des commits de la version à venir (je suis pour l'instant le plus gros contributeur de la version de développement de GIMP en cours!).
Mon objectif est d'essayer de sortir GIMP 2.10 au plus vite (idéalement j'aimerais que cela sorte avant Libre Graphics Meeting fin avril, mais je ne suis pas sûr si on y arrivera). Malheureusement les bugs bloquants font beaucoup de yoyo: plus on les corrige, plus de nouveaux arrivent. Mais le nombre descend tout de même globalement (19 à ce jour).

Système de debug

En début d'année, j'ai aussi eu une "révélation", après avoir traité un énième bug sans information utile, et quasi-impossible à reproduire: on doit avoir un système de débug!

C'est ainsi que j'ai décidé d'implémenter un tel système. Bon, je m'étais interdit de produire de nouvelles fonctionnalités, mais en l'occurrence, je crois que ça le vaut, et en un sens, c'est une fonctionnalité sans en être (son but étant surtout d'aider au débug; en soi ça n'apporte rien pour le traitement d'image ou le dessin numérique!). L'idée est donc de récupérer les informations de version de GIMP (version exacte, voire commit si build de développement, mais aussi les informations du compilateur utilisé, ainsi que les versions des dépendances principales) mais surtout de produire automatiquement une stack trace lors d'un crash, chose assez classique dans certains gros programmes. Mieux j'ai étendu cela aux erreurs critiques, et même possiblement à de simples warnings (cela est configurable, et par défaut les versions stables se limiteront aux crashs et aux erreurs critiques, mais les versions de développement remontent plus d'erreurs).

L'idée est donc d'encourager les gens à nous remonter les erreurs (le programme ne remonte pas les erreurs automatiquement, mais inclue un texte expliquant le processus et permettant de copier toutes les infos utiles d'un seul clic).

Techniquement, cela se base sur gdb, lldb, l'API GNU backtrace() pour les UNIX-like et Dr. Mingw pour Win32. J'ai aussi dû contourner les divers problèmes, comme le fait que dans un état instable de crash, l'application risque de ne pas pouvoir allouer de la nouvelle mémoire, ou la gestion du multi-threading, etc.
J'explique cela dans une entrée de journal un peu technique sur notre site (en anglais seulement).

J'en suis extrêmement heureux et fier car ça a déjà énormément aidé sur de nombreux bugs. Comme quoi, ça joue à rien!
En fait ce système de débug marche si bien qu'il explique une partie du travail des deux derniers mois puisqu'on a déjà probablement corrigé une bonne quinzaine de bugs remontés avec des traces utiles dès l'ouverture grâce à ce système.
Donc en un sens, ça nous a donné du travail, mais je le regrette pas. Ça n'en rend GIMP que plus solide!

Sauvegarde lors de crashs

Au passage, j'ai commencé à implémenter la sauvegarde automatique lors de crashs. Pour l'instant, la fonctionnalité est encore assez cachée (je n'ai pas encore fait de boîte de dialogue pour la récupération, etc.) mais la base est là. La GUI arrivera probablement bientôt.

Heureusement GIMP est plutôt stable, donc ce n'est pas non plus une urgence. :-)

Plus de journaux sur des sujets divers

J'ai décidé de parler un peu plus des choses sur lesquelles je travaille sur notre site, Studio Girin, même lorsque cela ne parle pas de GIMP ou que cela me paraît "petit" ou "dérisoire". En effet je me suis rendu compte qu'il est important de communiquer plus pour que les gens sachent ce qu'on fait, surtout qu'on le fait en se faisant financer par le public. Or cela fait des années que l'on fait des petites choses ici ou là, pour la plupart entièrement sous silence (comme énormément de gens dans le Logiciel Libre, soyons clairs là dessus!).

Ainsi dernièrement, j'ai parlé de la création d'un patch pour Ibus-Hangul (article en anglais aussi). Ibus-Hangul est notre entrée de clavier principale, et pendant quelques mois, la touche compose ne fonctionnait plus avec cette méthode d'entrée. Et c'était particulièrement embêtant, car je ne pouvais plus faire mes accents! Il m'est arrivé d'écrire des emails entiers avec des copier-coller de caractères accentués (quand je voulais vraiment écrire l'email avec un français propre).

Dans cet article, je raconte donc un peu le cheminement lorsqu'on part d'un simple constant de bug, puis un rapport de bug, qui se transforme en multiples rapports de bug. Il m'a en effet fallu 5 rapports de bugs sur divers projets, certains avec réponses, certains restés sans réponse pendant des mois, avant de simplement cibler le bon projet où le bug se produisait.
À la fin, j'ai corrigé le bug moi-même (ce que j'espérais ne pas avoir à faire, en bon développeur paresseux, mais comme on dit: on n'est jamais aussi bien servi que par soi-même), tellement je n'en pouvais plus de ne pas pouvoir écrire mes accents et autres caractères spéciaux.

Je pense que cet article est intéressant pour montrer comment on en arrive à patcher des projets divers (chose que je fais plutôt régulièrement) et comment cibler un problème, alors qu'on n'y connaît pas forcément grand chose dans un sujet donné.

J'ai aussi écrit un petit journal expliquant un script utilisé pour corriger des icônes de dossier (métadonnées GIO) après déplacement (une faille du design de la fonctionnalité, selon moi).

Désolé si tous mes journaux techniques sont en anglais, mais des fois, c'est fatigant d'écrire la même chose dans de multiples langues.

De la maintenance

Dans les autres projets pour faire avancer GIMP, nous avions besoin d'avoir un paquet des brosses MyPaint. En effet la version de développement de GIMP a depuis quelques temps la prise en charge du système de brosse de MyPaint.

Malheureusement, si le système de brosse est bien dans une bibliothèque séparée, libmypaint (un projet d'indépendance que j'avais aidé à l'époque), les brosses sont fournies avec le logiciel MyPaint lui-même. Or sans brosse, le système de brosse est un peu inutile, et cela faisait donc en quelque sorte de MyPaint une dépendance de-facto de GIMP.

Bien sûr, il est possible d'embarquer aussi ces mêmes brosses dans GIMP. C'est notamment la solution adoptée par OpenToonz apparemment. Mais de même que ce genre de choses est déconseillé pour une librairie, cela l'est pour les données. La duplication ne profite à personne: le set de données n'est plus synchronisé entre logiciels, si un bug est corrigé dans l'un, il ne l'est pas forcément dans les autres; si on ajoute une brosse dans l'un, elle n'est pas forcément disponible ailleurs non plus, etc. Imaginez si on devait dupliquer ces mêmes données dans GIMP, MyPaint, OpenToonz et tout autre projet utilisant libmypaint?!

J'avais donc ouvert une pull request depuis plus de 2 ans sur le projet MyPaint, avec la création d'un dépôt séparé pour les brosses, et les patchs pour l'utilisant dans MyPaint. J'ai suivi toutes les demandes de changement, et globalement les développeurs actifs comme le mainteneur sont pour ce changement. Mais la maintenance de MyPaint semble avoir un peu ralenti ces derniers temps.
Comme on a vraiment besoin de ces brosses dans GIMP, j'ai donc pris sur moi de maintenir pour l'instant ce dépôt de données, mypaint-brushes, ce que j'explique dans une autre entrée de journal. Ce fut l'une de mes premières actions de 2018.
Bien sûr, je n'attends qu'une chose: que le projet MyPaint me prenne le bébé des bras et s'en occupe eux-même au final!

À terme, je pense que cela ne peut qu'être bénéfique à MyPaint, GIMP et à tout projet utilisant libmypaint de se baser sur un paquet partagé de brosses que l'on pourra tous améliorer ensemble. J'enjoins donc les autres projets qui prennent aussi en charge les brosses MyPaint à utiliser ce paquet (et notamment à ne surtout pas embarquer une copie des brosses qui divergera seule avec le temps!).

De la collaboration

J'en reparlerai sûrement quand cela aura donné un changement concret dans GIMP, mais Americo Gobbo, un illustrateur professionnel utilisant GIMP, travaille sur de nouvelles brosses pour le set de base de GIMP. Pas seulement les siennes, mais aussi réunir diverses brosses libres de divers artistes.

C'était un projet que nous lui avions soumis, il y a déjà un an, lorsque nous l'avions invité lors du Libre Graphics Meeting 2017, car il est extrêmement intéressé par les brosses de GIMP.

Avec Aryeom, nous allons donc l'aider à finaliser ce set et à obtenir un compromis acceptable pour le renouveau des brosses de bases (les styles divergent, et les créateurs ne cherchent pas tous la même chose; il ne s'agit donc pas de juste rajouter le maximum de brosses sans bien réfléchir à leur utilité).

Un stagiaire FSF

Assez inattendu, un stagiaire FSF nous est tombé dessus l'autre jour.
J'ai trouvé le projet intéressant et ai donc commencé à discuter avec ce dernier, puis avec les gens de la FSF et ai finalement accepté d'être son mentor du côté GIMP. Je lui ai donné une première tâche parmi les quelques bugs bloquants restants (un des rares bugs que je pense être faisable par un étudiant stagiaire; la plupart sont simplement soit de niveau trop compliqué, soit nécessite pas mal d'expérience; ensuite bien sûr cela dépend aussi de la personne!).

Depuis ce week-end, je gère donc un stagiaire FSF pour une durée de 3 mois sur le projet GIMP!
C'est encore tout neuf, j'en reparlerai donc probablement.

Et des images!

Une animatrice en live

De son côté, Aryeom continue aussi ses lives réguliers. Si vous êtes intéressés par le sujet "Comment fait-on un film d'animation?", je ne saurais que trop vous conseiller de vous inscrire sur notre chaîne Youtube pour être mis au courant des lives, qui peuvent être souvent assez impromptus.

ZeMarmot fait-il de la Gym?

Pourquoi y a-t-il 2 ZeMarmot(s)?

D'autres projets à côté

Comme toute illustratrice, Aryeom a aussi besoin de dessiner d'autres choses, et s'entraîne quasi-quotidiennement à dessiner. Depuis 2016, elle publie notamment des dessins avec une autre amie illustratrice, Da Jung, sur le web: projet #Simwoool. Bien sûr, toutes les illustrations d'Aryeom sont libres (CC by-sa) et dessinées sous GIMP principalement (lorsque numérique).
Attention aussi bien la licence que les logiciels ne sont pas les mêmes pour son amie. Ne pas confondre si vous tombez sur des images du projet Simwoool et souhaitez les rediffuser, car la moitié sont en CC by-nc-sa. Seules celles d'Aryeom sont en CC by-sa et dessinées avec du Logiciel Libre.

Cette année, elles ont donc décidé de mettre leurs illustrations du projet dans un petit livre (non commercialisé). Aryeom a fait la mise-en-page dans Scribus bien entendu et elle a imprimé et fait la reliure elle-même (chose qu'elle avait déjà faite de nombreuses fois, et sérieusement son livre a l'air aussi bien que les livres du commerce!) selon la technique de "perfect binding" (pas sûr du terme français).
On se dit d'ailleurs qu'un jour on pourrait faire un atelier de reliure de livre à l'association LILA si cela intéresse des gens!

Geek Faëries on the web

Fin janvier, nous avons aussi participé aux Geek Faëries on the Web. Aryeom a fait une démo live d'animation ZeMarmot, comme on le fait habituellement.
Voici le bout d'animation rough fait par Aryeom pendant cette démo:

Puis Aryeom a terminé par un speedpainting de remerciement. On s'est dit que les gens de Geek Faëries aimaient les dragons, donc voici le résultat du SpeedPainting, 15 min dans GIMP:

De mon côté, j'ai surtout parlé et répondu à des questions pendant la démo.
Cela s'est globalement bien passé même s'il y a eu des problèmes techniques (ils espéraient nous faire utiliser Skype ou autre solution propriétaires, les pauvres! À la place, on a réussi à leur faire recevoir le flux vidéo de notre solution libre OBS). Et encore, on était troisième sur le planning "libriste", mais le premier a dû être annulé, tout simplement! Donc on s'estime heureux d'avoir pu être diffusé malgré les quelques problèmes qui ont généré plusieurs coupures pendant la démo.

On ne sait pas trop quand et s'il y aura des enregistrements.

Et voilà!

C'est donc une année qui commence à peine. Nous n'en sommes qu'à la fin du deuxième mois. Mais tant de choses se sont déjà passées et tant de choses ont été faites. C'est vraiment une année qui peut être charnière. On l'espère en tous cas.

Et on veut donc vous rappeler que vous pouvez donner à ZeMarmot pour nous aider à continuer! Que ce soit pour le code majeur dans GIMP, comme des patchs mineurs dans d'autres logiciels (comme je l'ai montré), ou pour de l'Art Libre, ou simplement un peu "d'éducation populaire" et autre passage de connaissance, vous pouvez contribuer financièrement pour nous permettre de continuer.

ZeMarmot a encore et toujours besoin de vous pour continuer son voyage graphique et logiciel!

Nous sommes désormais disponible sur Liberapay, qui commence à être une plateforme qu'on apprécie beaucoup (gérée associativement, sans frais de plateforme, et d'une simplicité reposante).
Sinon on est bien sûr toujours disponibles sur Tipeee et Patreon.

Il existe d'autres moyens de donner, que ce soit par virement bancaire ou chèque à l'association LILA, Paypal direct ou même en bitcoin (tout est sur la page de donation du projet ZeMarmot).

Voilà, en espérant que vous pouvez nous aider si vous appréciez notre projet, et bien sûr si vous pouvez vous le permettre.
Dans tous les cas, je vous souhaite une bonne semaine.
Et puisqu'on vient à nouveau, et tout juste, de passer un autre type d'année, l'année lunaire, je vous souhaite une bonne année du chien!