Journal Les dernières News de ZeMarmot

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
45
28
fév.
2018
Ce journal a été promu en dépêche : Les dernières nouvelles de ZeMarmot.

Sommaire

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).

système de débug

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).

Compose Key dans GNOME

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).

Icônes personnalisés dans Nautilus

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

Les oiseaux volent aussi le vendredi

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.

Oh hisse
ZeMarmot fait-il de la Gym?

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

D'autres projets à côté

Simwoool couverture

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!

Dessin d'Aryeom
Autre dessin d'Aryeom

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:

Animation durant Geek Faëries

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:

15 min speed painting

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!

Bonne année du chien

  • # Merci

    Posté par  (site web personnel) . Évalué à 4.

    C'est vraiment une année qui peut être charnière. On l'espère en tous cas.

    Et bien d'autre avec vous l'espère aussi :-)
    Bon courage.
    Et surtout merci pour le boulo accomplis !

    kentoc'h mervel eget bezan saotred

  • # Reliure

    Posté par  . Évalué à -4.

    Bonjour, le perfect binding c'est du collé ? Ça reste du bas de gamme en terme de reliure. C'est orienté magazine pas trop épais, livre de poche (et encore…). Les feuilles finiront par se barrer.

    Si le contenu vaut le coup il faut coudre. C'est plus long à faire. Pour le in-plano fait être un peu inventif (pas de méthode toute faite sauf reliure japonaise).

    Y'a plein de vidéos sur YouTube qui montre des reliures d'art. Pas besoin d'avoir tout la matériel qu'ils ont, on peut faire des choses sympas avec peu de moyens de l'imagination et quelque expérience. Notamment pour rajouter une couverture solide. Mais c'est un poil chronophage.

    • [^] # Re: Reliure

      Posté par  (site web personnel, Mastodon) . Évalué à 5.

      Alors "bas de gamme", c'est vite dit. C'est simplement l'une des reliures professionnelles parmi les plus répandues dans le commerce. Ensuite une fois fini, ça a vraiment l'avantage de faire pro et nickel, même si fait artisanalement (comme était le cas de cet exemplaire). Une reliure au dos collé bien faite, franchement, ça rend bien (il faut voir celle du bouquin fait par Aryeom, on croirait qu'il vient de l'imprimeur).

      Alors certes, on voit toutes sortes de "reliures d'art" sur Youtube (c'est pas forcément une référence), comme tu dis. Tout le monde y va de son tuto. C'est clair que ça fait plus classe de dire qu'on fait une "reliure japonaise" qu'une "reliure collée". J'ai vu des ateliers par dizaines pour faire de la reliure japonaise et jamais pour de la reliure collée. En fait Aryeom est la première personne que j'ai rencontrée qui faisait de la reliure collée sur des livres faits-mains. Ben franchement à chaque fois que je vois le résultat, je suis épaté. C'est pratique, c'est classe, classique et simple, et ça se fait pas remarquer. Ben perso c'est tout ce que je demande à une reliure.
      Le fait que ce soit plus simple et moins cher à produire, ce qui est sûrement la raison pour laquelle tu l'associes à du "bas de gamme" ne sont pour moi que des avantages additionnels, pas des inconvénients.

      Je sais pas si tu as déjà vu une reliure japonaise (qui d'ailleurs ­— même si aussi utilisée traditionnellement au Japon — serait plutôt une reliure chinoise historiquement, mais ça fait juste plus "classe" de dire "reliure japonaise"; enfin je suppose que c'est la raison de l'emploi impropre de l'origine japonaise partout où c'est cité), mais c'est bien moins pratique (en particulier vraiment beaucoup de perte d'espace) et c'est très visible (ce qui peut être un choix design).

      C'est orienté magazine pas trop épais

      Bien au contraire, la reliure collée est très adaptée aux livres épais.

      livre de poche (et encore…)

      Ben si, la plupart des livres de poche sont avec dos collé. Pour info, je viens de sortir un recueil de plusieurs romans de Herman Hesse en version poche de ma bibliothèque. Comme attendu, il est aussi avec reliure collée et fait quasi 2000 pages.

      Ah et encore une fois, perso je n'associe même pas "livre de poche" à bas de gamme, même si c'est ce que beaucoup d'éditeur essaient de donner comme image (simplement car ils veulent vendre le même livre plus cher). Il se trouve que je préfère les poches. C'est plus facile à transporter, moins lourd, moins chiant. Et la grosse couverture en dur, je m'en passe vraiment avec grand plaisir au profit d'une couverture souple (qui sera tout de même dans un papier un plus épais) plus maniable.
      Ensuite c'est une question de goût (certains préféreront les gros livres avec gros caractères, etc.) mais pas si nettement de "gamme" pour moi.

      Les feuilles finiront par se barrer.

      Bien sûr, c'est plus facile qu'avec une reliure cousue, mais j'arrache pas non plus une feuille de mes livres de poche tous les 4 matins. Ensuite, je sais pas pour toi.

      Voilà. Tout ça pour dire que je ne dis pas que tu as entièrement tort. Bien sûr que les livres aux reliures cousus sont plus solides et donc plus "pérenne" dans le temps. Mais ça n'en rend pas pour autant les reliures collées comme une technique à dédaigner (sinon ça serait pas utilisé massivement dans l'industrie du livre). Et si on devait monter en solidité vraiment, je conseillerais d'ailleurs les sections cousues puis collées (l'autre méthode de reliure très répandue, celle qu'on voit le plus souvent pour des livres à couverture dure, ou pour des manuels, etc) et pas les "reliures japonaises chinoises".

      Dans tous les cas, si quelqu'un s'intéresse au sujet, faut savoir ce qu'on veut: du hype ("reliures japonaises chinoises" et autres "reliures d'art" hype) ou des reliures pratiques et qui savent se faire oublier (collée, ou cousu par section puis collé) pour relier de vrais livres qu'on veut imprimer pour soi (et pas juste faire un effet démo). Bien sûr que les techniques dites "d'art" sont cools aussi. Je dirais que c'est à utiliser si tu veux faire un livre "exotique" où le fait d'avoir une reliure bien visible est un choix design. Mais ce n'est pas mieux. Perso le fait que la reliure puisse ne pas se faire remarquer dans un livre est un choix très valable.

      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.