ZeMarmot

ZeMarmot

Page vérifiée Created at April 4, 2016 Contact

ZeMarmot Monthly report: August 2019

- 0
  • [ français — English below ]

    Encore un mois des plus mouvementés! 😃 Voyons donc ce qu'il s'est passé dans notre studio associatif:

    # Animation

    Aryeom a continué à travailler sur une scène assez longue. Plus que des mots, on vous montre quelques images animés dans la vidéo ci-dessus. Quelques séquences furent animées ce mois-ci, d'autres sont un peu plus vieilles. Vous remarquerez que pas tout n'est animé encore.

    Nous avons aussi inclus une petite séquence qui va direct à la poubelle, par transparence du fonctionnement du travail d'animateur. Ici, petite erreur 😅, une entrée de terrier fut oubliée! Par conséquent nous avons animé la marmotte qui court vers le mauvais terrier! (pourquoi en effet irait-elle se cacher dans un trou au loin si elle en a un juste à ses pieds? Ce serait une erreur de script). Comme dans tout travail, les erreurs font partie du quotidien. Il faut savoir faire avec. De même qu'en développement, pour quelques lignes de code que vous voyez, si vous saviez le nombre de lignes qui furent testées puis jetées!…

    # Santé

    Aryeom a aussi eu quelques problèmes d'épaule et de dos dernièrement, donc elle a encore eu une série de rendez-vous chez la kinésithérapeute. En parallèle, nous avons cherché à améliorer ses conditions de travail, ce qui n'est pas une tâche aisée, car son travail est stressant pour le corps presque par nature (passer des heures à dessiner). On se dit qu'il faudra qu'on fasse un article dédié sur le sujet des positions et du matériel un jour, car c'est un sujet intéressant et surtout très important pour tous les artistes numériques.

    # Prise en charge des greffons Python 3, JavaScript et Lua dans GIMP 3

    Côté GIMP, un sujet de longue date était le besoin de passer à la prise en charge de Python 3 (GIMP prend actuellement en charge les plug-ins en Python 2, or la fin de vie de Python 2 est programmée pour janvier 2020!) mais personne ne semblait prêt à travailler sur ce port. Sur ZeMarmot, nous n'avons pas urgemment besoin de cela, mais nous sommes conscient que c'est un prérequis nécessaire pour GIMP. C'est un pari sur le long terme. Jehan a donc décidé de s'y pencher. De manière surprenante ce ne fut pas si complexe. En juste quelques heures, on avait un greffon démo tournant avec Python 3. Par contre, comme le diable se cache dans les détails, c'est vraiment tout les petits détails qui ont pris 3 semaines à être mis en place.

    Comme cette nouvelle implémentation est basée sur GObject Introspection (une suite d'outil qui extrait les métadonnées d'une bibliothèque C pour permettre la création de bindings, c'est à dire une liaison avec d'autres languages), GIMP a en fait obtenu la prise en charge d'autres langages, potentiellement.

    À ce jour, nous avons confirmé la prise en charge des langages suivants (c'est à dire que nous avons écrit des greffons de démonstration et fonctionnels): Python 2 et 3 (vous remarquerez que la prise en charge de Python 2 n'a pas disparu, bien que nous ne ferons pas d'effort particulier dans ce sens), JavaScript et Lua.

    # Meilleur accompagnements des développeurs de greffons

    Vous vous rappelez sûrement que Jehan travaille aussi avec passion sur le système de gestion des extensions de GIMP. Pour nous, c'est en fait le même sujet. GIMP a eu beaucoup de greffons tiers dans son histoire, celle-ci étant longue de nombreuses années. Mais on voit clairement que ces greffons sont peu maintenus, perdus sur des sites abandonnés sur le web, et parfois même certains extrêmement intéressants n'ont pas le suivi qu'ils méritent. Il existe aussi de nombreux tutoriels sur le web, et bien sûr sur le site officiel de GIMP même, mais la qualité de ces tutoriels laisse souvent à désirer.

    Un de nos souhaits est donc d'améliorer l'écosystème de greffons, non nécessairement en quantité, mais surtout en qualité. Bien sûr, il faudra que nous écrivions de meilleurs tutoriels d'une part. Une autre étape est d'avoir des exemples concrets à suivre. Nous avons donc créé dans GIMP 3 un nouveau sous-menu "Développement" qui contient des greffons de démonstrations dans tous les languages officiellement confirmés. Ces greffons afficheront leur propre code dans une fenêtre et font tous le même traitement simple (inversion de couleur avec GEGL) sur l'image active. Un lien est aussi cliquable si vous souhaitez accéder à la dernière version du code en ligne pour le lire dans de meilleurs conditions.

    # Interface de greffon GIMP améliorée

    Mitch, notre cher mainteneur, a sauté sur le train des greffons et a fait un superbe travail (comme toujours) pour rendre l'interface (API) bien plus agréable pour créer des greffons. Pendant ce temps, Jehan a aussi rendu l'interface orientée objet. Un des effets de bord sympathique est que le code des scripts sera bien plus simples.

    Ainsi l'équivalent de ce code C:

    > dup = gimp_image_duplicate (image);

    est:

    > dup = image.duplicate()

    (désolé si vous n'êtes pas trop dans la technique, cela n'est peut-être pas très excitant! 🤔)

    # Travail en cours: communication bi-directionnelle avec les greffons

    Une autre conséquence très sympa sera qu'on veut se raccrocher aux systèmes de signaux de GObject pour fournir une infrastructure de signaux de GIMP vers les greffons. En effet l'une des limitations majeures du système de greffon actuel est que la communication est à sens unique: les greffons peuvent contacter GIMP pour obtenir des informations, mettre à jour des images ou demander des changements; par contre GIMP ne peut pas contacter les greffons, hormis au moment du lancement.

    Notamment les greffons ne sont pas notifiés lorsque des images sont crées, supprimées, lors des calques sont ajoutés, mis à jour, déplacés ou retirés, ou quand diverses actions sont faites.

    Nous avons nous-même un cas d'usage puisque le GIMP que nous utilisons a en fait une petite modification sur la façon donc les calques sont renommés automatiquement (vous savez, lorsque vous créez un calque et qu'il s'appelle "Copie de calque" ou encore "Calque #1", puis "Calque #2", etc.) Nous voulions un algorithme de renommage légèrement différent mais cela ne fut jamais intégré à GIMP car cela change une logique à laquelle les gens se sont habitués depuis des dizaines d'années. Ce n'est pas un problème. GIMP n'est pas que pour nous et c'est normal de faire des compromis pour le cas général. Par contre, ne serait-il pas mieux si les greffons autorisaient à personnaliser GIMP, chacun selon ses spécificités d'usage?

    Je me rappelle aussi de demandes de fonctionnalités que nous avons dû refuser dans le passé car ils allaient contre l'usage acquis. Par exemple on se souvient de quelqu'un qui voulait utiliser les couleurs d'avant et arrière plan d'une manière particulière avec des retournements automatiques. Nous avons bien entendu dû refuser car les concepts d'avant/arrière plan sont simples par concept et ne doivent pas être ainsi dévoyés pour des usages particuliers. Cependant ce jour là, j'aurais aimé pouvoir répondre à cette personne « désolé, nous ne changerons pas GIMP, mais vous pouvez faire très facilement ce que vous souhaitez avec un greffon ».

    Si tout se passe bien, nous pourrons bientôt dire ce genre de choses aux gens! Bien que Jehan ait déjà une implementation fonctionnelle (ce n'est donc pas théorique, la fonctionnalité est quasiment là), c'est encore considéré comme travail en cours car nous discutons des implémentations alternatives qui pourraient être meilleures techniquement.

    Notons finalement que nous sommes conscients que les deux exemples peuvent paraître absurdes. Pourquoi le nommage automatique des calques ou l'usage des couleurs de premier ou d'arrière plan importerait tant? Individuellement ce n'est pas si grave. Mais qu'importe si on considère ces quelques exemples comme peu pertinents pour soi? C'est la possibilité de faire de GIMP ce que l'on veut qui importe! Pouvoir améliorer ses outils soi-même, bidouiller son processus de travail, se simplifier la vie et améliorer ses tâches quotidiennes en intégrant des changements qui peut-être n'ont aucun sens pour le commun des gens mais font toute la différence pour soi! Qui peut juger de cela sinon soi-même?

    C'est ainsi que ce qui importe sont des logiques saines par défaut et la possibilité de personnalisés ces logiques pour les modeler à nos usages particuliers. Cela n'en ferait-il pas un outil ultime?

    Nous espérons donc que vous avez apprécié notre rapport d'août!

    À bientôt! 👋

    Équipe ZeMarmot

  • [ English ]

    This month was a bit hectic… again! 😃 Here is what happened lately in our non-profit studio:

    # Animation

    Aryeom continued working on a long scene, but more than words, we thought we'd show you some more images this month in the above video. Some parts are newly done, some were done before, and you'll note that some cuts are not animated yet.

    In the video, we also included a small cut which is going to the trash. We did it for transparency of how animation works, and the errors anyone can make 😅. In this case, because a burrow hole was forgotten, she animated the wrong marmot's movements (why would the marmot go and hide in a far-away burrow when there is one just under! It would clearly be a script error). It's actually quite interesting to see that in any job, errors are part of the job. Just as in software development too, you can only see a small part of the code. To get there, how many lines of code were tested then trashed away?!

    # Health

    Aryeom also has some back and shoulder issues, hence have been seeing (again) a physiotherapist lately. So we have been working on improving a bit her work conditions. It's hard because her job is inherently very difficult and straining for the body. I think we should do a dedicated post at some point about the issue of work positions and material, because it is quite an important topic for any digital artist out there.

    # Support of Python 3, JavaScript and Lua plug-ins in GIMP 3

    On GIMP side, a long-running topic has been supporting Python 3 plug-ins (GIMP currently supports Python 2 plug-ins, whose end of life support is supposed to be on January 2020!) but nobody seemed able or willing to work on it. We don't necessarily need this urgently for ZeMarmot but it is obviously a hard requirement for GIMP as a whole, so Jehan decided to give it a look. Unexpectedly it was quite easy and we got a working proof-of-concept Python 3 plug-in in just a few hours. As we all know, the details is what really takes time, so in the end, it took a whole 3 weeks. Since the new implementation is based on GObject Introspection (tools to extract metadata from a C library, hence allowing to create bindings from other languages), we even gained simultaneously support for many other languages.

    The new supported languages for GIMP plug-ins which have been confirmed so far (i.e. we were at least able to create demo plug-ins) are: Python 2 and 3 (yep we didn't even lose Python 2 support, though we obviously won't give much efforts there), JavaScript and Lua.

    # Better accompany plug-in developers

    You know Jehan is also working on the extension management system and website. This is a whole and same topic actually. Up to now, GIMP has a lot of plug-ins because it has been there for so long. But maintenance over time is not often there and finding support for plug-in creation has always been a hard task (there are some tutorials on the web, and of course on the official GIMP website too, but seriously most are terrible).

    We'd like to get a saner plug-in ecosystem so we'll try to write up some better tutorial in the future. And as a first step, we decided to write a demo plug-in for every supported language we confirmed to work. So in GIMP 3, you will find a new "Development" menu with demo plug-ins. They show their own code and all do the same very simple image manipulation (inverting colors with GEGL). A link is also present which sends you to the last version of the source code online, in case you want to see the code in better conditions, or simply download it.

    # Improved GIMP API

    Mitch, our dear maintainer, jumped in on the plug-in train and did an awesome work (as usual) to improve the existing API. Creating plug-ins has become much nicer now. In the meantime, Jehan worked to add object-orientation in the API. One of the nice side effects is that introspected bindings are now nicer to write. So for instance the Python equivalent of:

    > dup = gimp_image_duplicate (image);

    is:

    > dup = image.duplicate()

    (sorry if you are not into techniques and don't see the point of this part! 🤔)

    # Work-in-progress: bi-directional communication with plug-ins

    The other very cool side effect it will have is that we want to be able to hook into the signal system of GObject to provide core to plug-in signalling. Basically one of the most crucial limitations of GIMP plug-ins is that it is mostly mono-directional: plug-ins mostly contact GIMP core to get information, or to request changes, to update images, and so on; on the other hand GIMP cannot tell anything to plug-ins, except at start.

    In particular plug-ins don't get notified when images get created or removed, when layers are created, updated, reordered or deleted, or when various actions are done.

    We have one such example ourselves. Atop our own builds of GIMP, we have a commit for different automatic renaming of the layers (you know, when you create a new layer and it is named "Layer Copy", then "Layer #1", "Layer #2" and so on). We wanted something different but our commit never made it to GIMP because it just changes logics people have been getting used to for dozens of years. Well it's fine. GIMP is not just for us and it's normal to make compromises. Yet it would be nice if plug-ins were able to customize GIMP how people want it for personal use cases.

    I also remember someone who once made a report because one was using the foreground/background colors in a specific way and wanted some automatic color switch or something. Anyway this obviously had to be refused. FG/BG colors have a specific usage logic and we can't change this to cater to anyone whim. Yet I always wished I had been able to tell this person « sorry we won't change GIMP, but you could very easily make a plug-in which does this for you ».

    Well hopefully we soon will. Though Jehan already has a working implementation (so it's nothing theoretical, it's basically nearly there), this is still work-in-progress as we are discussing alternative implementations which may be technically better.

    Also note that both the layer naming or the FG/BG colors examples may sound silly. One might wonder why it matters so much. Well these individually don't matter much. Really. I would perfectly agree if someone thought our wish to different automatic naming algorithm was a bit useless; as much as I find the desire to use FG/BG colors in unexpected ways weird too. But who cares? The point is to give people the possibility to use GIMP however they want, and however it will improve, simplify or speed up their workflow. Who is anyone else to judge if it actually helps them?

    Sane defaults and good customization support is a very good bargain in our opinion. Wouldn't it make it an even better tool?

    We hope you enjoyed our August report!

    See you soon! 👋

    ZeMarmot team