Le point sur mes projets : un lifting pour YOGA, la fin de Nautilus Terminal, diverses mises à jour pour CalCleaner et Rivalcfg

Ça fait presque trois mois que je n'ai pas publié d'article (le dernier datant de début août), il est donc grand temps de remédier à ça ! Car si je n'ai pas été très actif sur le blog, j'ai en revanche beaucoup (trop) travaillé sur mes autres projets durant ces derniers mois. On va donc faire un peu le point sur tout ça ! 😋️

Au sommaire de cet article :

Un petit lifting pour YOGA Image Optimizer

Logo de YOGA Image Optimizer

YOGA Image Optimizer est une interface graphique pour la bibliothèque YOGA que je développe sur mon temps libre. Cet outil permet d'optimiser les images par lot et supporte actuellement les formats JPEG, PNG et WebP en sortie.

La dernière release du logiciel, la version v1.1.1, était sortie il y a environ 1 an. Il était donc grand temps de s'y remettre. Depuis la rentrée, deux versions de YOGA Image Optimizer se sont succédées.

Version v1.1.2 : traductions

La première, estampillée v1.1.2 est sortie mi-septembre. Il s'agit d'une version mineure : elle n'embarque que de nouvelles traductions. J'avais en effet reçu quelques contributions de ce côté-là, mais n'ayant pas eu le temps de bosser sur le projet, elles n'avaient pas été publiées...

Je me suis rendu compte à l'occasion que j'avais tendance à attendre d'avoir quelques fonctionnalités ou correctifs sous le coude pour sortir de nouvelles versions, avec une mise à jour des traductions au passage... Ce qui est assez dommage puisqu'on peut facilement se retrouver avec des traductions qui attendent pendant plusieurs mois dans le dépôt Git sans profiter à personne. Dorénavant je m'efforcerai de sortir les nouvelles traductions plus rapidement.

C'est lors de la sortie de cette version que j'ai également tenté de rendre le processus de traduction plus accessible, via l'interface web POEditor... Après quelques semaines de recul, je continue de penser qu'une interface web est bénéfique pour les traducteurs, mais je pense que POEditor n'est pas le bon outil. Il manque d'automatisation : je dois lancer les synchronisations vers et depuis le dépôt Git à la main, et je dois lier manuellement chaque fichier de traduction à une langue à la main,... Bref trop de manipulations pour quelque chose qui devrait être entièrement automatisé !

Pour plus de détails, je vous invite à lire la news sur le site de YOGA :

Version v1.2.0 : interface graphique et UX

En octobre je me suis concentré sur l'amélioration de l'interface graphique et de l'expérience utilisateur de YOGA Image Optimizer. C'est ainsi que la version v1.2.0 est sortie vers la fin du mois.

Au programme, une interface retravaillée pour être plus compacte et moins chargée, notamment au niveau de la liste des images dans laquelle des colonnes ont été fusionnées et les informations affichées sur plusieurs lignes. Le volet d'options situé en bas de la fenêtre a également été réorganisé avec des onglets, ce qui permettra de rajouter les futures options et transformations sans se retrouver avec une interface complètement imbuvable.

Capture d'écran de YOGA Image Optimizer v1.2.0

Capture d'écran de YOGA Image Optimizer v1.2.0

L'autre gros travail de cette version a été la gestion des miniatures. Auparavant elles étaient générées directement dans le processus principal lors de l'importation des images... ce qui avait tendance à poser quelques problèmes lorsque l'on importait un dossier plein de photos par exemple. L'application pouvait ainsi se retrouver complètement figée pendant plusieurs dizaines de secondes, le temps de générer les miniatures.

Mais ça, c'est du passé ! Maintenant lorsque les images sont importées, un placeholder est affiché à la place de la miniature, et cette dernière est ensuite générée dans un autre thread et sera affichée lorsqu'elle sera prête.

Et pour éviter de refaire un travail qui a déjà été fait, YOGA Image Optimizer tire parti du cache partagé des miniatures (sous Linux tout du moins). Explication : lorsque vous naviguez dans vos dossiers avec votre navigateur de fichiers préféré (Nautilus, Dolphin, Thunar,...) ce dernier génère les miniatures des images et il les stocke dans un dossier de cache, qui est partagé entre toutes les applications. YOGA Image Optimizer va donc piocher dedans et ne s'embête à calculer les miniatures que lorsque cela est nécessaire.

Génération asynchrone des miniatures (la génération a été ralentie pour la capture vidéo afin qu'on ait le temps de bien voir ce qu'il se passe)

Cette version apporte également une meilleure gestion des erreurs, pas mal de correctifs, et que quelques traductions supplémentaires.

Pour plus de détails, notamment si vous voulez des comparatifs avant / après de l'interface, vous pouvez lire la news sur le site officiel de YOGA :

Quelques ratés à l'allumage

La version v1.2.0 a connu quelques ratés lors de sa sortie. Le logiciel en lui-même fonctionnait sans problème et avait été particulièrement bien testé avant sa sortie... Mais des soucis se sont glissés dans les livrables. 😮‍💨️

La version Windows pour commencer. Je la compilais et la distribuais avec une version trop ancienne de GTK 3. Malheureusement, j'ai commencé à utiliser des fonctionnalités dans les markups de Pango qui n'étaient pas disponibles dans cette version... et forcément, ça s'est mal passé. Pas de crashes à l'horizon mais les informations affichées dans l'interface ne s'actualisaient pas... Plutôt gênant...

J'ai donc dû mettre à jour la version de GTK 3 utilisée, mais pour cela il me fallait une nouvelle version de Visual Studio, mais impossible de l'installer dans la machine virtuelle existante... Au final je me suis retrouvé à reconstruire une nouvelle machine virtuelle Windows 11 pour la compilation du projet.

J'ai également mis à jour Nuitka, le compilateur Python que j'utilise pour distribuer des versions autonomes du logiciel sous Windows (je ne vais pas demander aux utilisateurs d'installer Python et de compiler GTK eux-mêmes). Sauf qu'il y avait un petit bug justement lié à GTK dans cette nouvelle version... Mais heureusement le problème est en cours de résolution ! Je remercie d'ailleurs le maintainer du projet qui est toujours très réactif ! 😁️

La version Windows est à présent fonctionnelle, mais il reste quelques rares cas de crashes lors du drag & drop d'image que je n'ai pas encore réussi à régler... Le support de cette plateforme est un travail sans fin ! 😓️

Le paquet Flatpak distribué sur Flathub a lui aussi connu quelques ratés. Un outil de la chaîne de compilation a subitement décidé de rajouter un flag (_GLIBCXX_ASSERTIONS), qui a dévoilé un bug présent depuis toujours dans la bibliothèque Guetzli (l'un des encodeurs JPEG utilisés par YOGA).

Du coup, lors de l'optimisation de certains JPEG, le processus crachait. Pour la faire courte, la bibliothèque faisait de mauvais accès mémoire, elle débordait parfois d'une case en accédant à des Vectors. Ce genre de problème devrait normalement causer un segfault de l'application, mais par « chance » la mémoire des Vectors est allouée avec un peu de marge pour des questions d'optimisation. Ça a pris un peu de temps à trouver d'où venait le problème et à le corriger. J'en profite pour remercier DindinX sans qui je serais encore en train de travailler sur ce bug ! 😁️

Et ensuite ?

Cette version de YOGA Image Optimizer était un gros point d'étape pour moi, et j'ai encore pas mal de boulot à faire sur ce projet.

Pour commencer, je voudrais intégrer des options pour réduire le nombre de couleurs dans les images. La fonctionnalité est déjà implémentée dans YOGA, il ne reste qu'à l'ajouter dans l'interface graphique.

J'ai aussi des améliorations sur le feu pour l'optimisation des JPEGs. Je voudrais notamment ajouter un preset qui ne ferait appel qu'à MozJPEG, ce qui permettrait d'optimiser beaucoup plus rapidement les JPEG (mais avec une efficacité moindre) et cela ouvrirait également la porte aux optimisations sans perte pour ce format (pour peu que l'image d'entrée soit déjà un JPEG).

À plus long terme, j'ai toujours le projet d'ajouter le support de nouveaux formats d'images comme l'AVIF et le JpegXL, mais je n'ai aucune idée de l'échéance à laquelle j'arriverais à me mettre sur ces sujets-là.

Première version stable et des traductions pour CalCleaner

Logo de CalCleaner

CalCleaner c'est mon petit projet de l'été. Il s'agit d'un outil permettant de purger les vieux événements des calendriers CalDAV. Simple, et efficace ! Je l'utilise régulièrement pour dépoussiérer mes calendriers Nextcloud.

Je vous avais parlé de la naissance de cet outil dans le précédent article du blog que je vous invite à lire si vous voulez plus de détails à son sujet :

Captures d'écran de CalCleaner

Captures d'écran de CalCleaner v1.1.1

Depuis cet article, dans lequel je parlais de la version v0.9.1 encore en beta, plusieurs versions de CalCleaner ont paru.

Tout d'abord la v1.0.0, première version stable du logiciel sortie le 20 août. Elle corrige quelques petits bugs, ajoute une option pour accepter les certificats SSL autosignés, et une première traduction (en dehors du français) a fait son apparition : l'italien.

Début octobre c'est au tour de la version v1.1.0 de sortir, avec quelques améliorations internes dans la manière dont l'interface est codée (qui apporte entre autres une meilleure accessibilité). Deux nouvelles traductions sont également de la partie : le hollandais et le brésilien.

Comme pour YOGA Image Optimizer, c'est sur lors de cette version que j'ai mis en place l'outil POEditor pour simplifier le travail de traduction. Mais comme pour ce dernier, il faudra que je trouve autre chose à cause du manque d'automatisation.

Enfin, la version v1.1.1 est sortie il y a seulement quelques jours, avec une traduction en Allemand (j'avais bien dit que j'allais sortir plus rapidement les nouvelles traductions 😉️).

Pour ce qui est du futur du logiciel, je n'ai pas de plans à court terme : j'ai déjà bien assez à faire avec YOGA et Rivalcfg, sans compter les articles de ce blog. Toutefois, quelqu'un m'a fait remarquer qu'il n'était pas forcément aisé de connecter CalCleaner à un calendrier CalDAV.

Lorsqu'il s'agit de Nexcloud c'est assez simple puisqu'il permet de récupérer les URLs des calendriers directement depuis son interface. Mais pour les solutions comme Google Agenda ou iCloud, c'est bien plus compliqué (sans compter les histoires de connexions OAuth pour Google Agenda). 😓️

Capture d'écran de la récupération de l'URL du endpoint CalDAV sur Nextcloud

Récupération de l'URL des calendriers CalDAV sur Nextcloud

Il est donc possible que je travaille à l'amélioration de ce point d'ici quelques mois, en ajoutant des assistants de configuration pour les principaux fournisseurs de calendrier.

Toujours plus de souris supportées par Rivalcfg

Logo (non officiel) de Rivalcfg

Rivalcfg est un outil en ligne de commande et une bibliothèque Python permettant de configurer les souris gaming de la marque SteelSeries. Il a été conçu principalement pour Linux puisque le fabricant ne fournit aucun support pour cette plateforme, mais il fonctionne également sous Windows et macOS (et très probablement sous BSD mais je n'ai pas testé).

Le développement de Rivalcfg poursuit tranquillement son cours avec 3 versions sorties tout au long de l'année (une en janvier, une en août et une en septembre). Ces versions on principalement amélioré ou ajouté le support de nouvelles souris dont voici la liste :

  • Aerox 3 Wireless (amélioration du support)
  • Aerox 5 Wireless
  • Aerox 9 Wireless (support partiel, il faut encore que je bosse sur le binding des boutons. J'ai déjà récupéré toutes les infos nécessaires mais je manque juste de temps pour m'en occuper)
  • Prime CS:GO Neo Noir Edition
  • Prime Rainbow 6 Siege Black Ice Edition
  • Prime Wireless
  • Rival 100 (amélioration du support)
  • Rival 3 Wireless
  • Rival 650 mouse (support partiel, il manque encore la configuration des LEDs. Mais comme je possède la souris, ce n'est qu'une question de temps)

Au final c'est pas moins de 55 modèles qui sont supportés, sur un total de 81 souris de la marque.

C'est pas si mal, sachant que je ne possède pas la plupart de ces souris, ce qui rend leur support assez difficile. Il faut ainsi trouver des utilisateurs motivés et ayant suffisamment de compétences techniques pour, à minima, capturer des trames USB que je pourrais ensuite analyser.

En dehors du support de nouveau matériel, ces versions ont apporté quelques améliorations et quelques corrections de bugs. Pour plus de détails vous pouvez lire les changelogs sur le dépôt Github :

Et pour la suite ?

Je pense que Rivalcfg va continuer à évoluer au fil des contributeurs qui me fourniront de la matière pour supporter de nouveaux modèles. J'aimerais bien aussi développer une interface graphique. J'avais d'ailleurs fait un PoC en live sur Twitch il y a plus d'un an maintenant, mais je n'ai jamais eu le temps d'aller plus loin : j'ai priorisé le support de nouveaux modèles (pendant que j'avais les contributeurs sous la main).

Capture d'écran du PoC d'interface graphique de Rivalcfg

PoC d'interface graphique de Rivalcfg

La fin de Nautilus Terminal

Logo de Rivalcfg

Ah Nautilus Terminal... C'est la nouvelle triste du jour. Après 12 ans à développer et à maintenir ce logiciel, il semblerait bien que ce soit la fin. 😟️

Pour ceux qui ne connaissent pas le projet, Nautilus Terminal est un plugin pour Nautilus, le navigateur de fichiers de GNOME. Ce plugin intègre un terminal directement dans la fenêtre du navigateur de fichers, qui suit automatiquement la navigation lorsque l'on change de dossier. Il est très pratique pour taper rapidement une commande dans le dossier courant.

Capture d'écran de Nautilus Terminal

Nautilus Terminal intégré dans Nautilus

Pourquoi cet arrêt ? Que s'est-il passé ?

Depuis sa version 43 sortie il y a peu, Nautilus est (enfin) passé à GTK 4. Cette migration a été l'occasion pour les développeurs de faire le ménage dans le logiciel et ses APIs... Et l'API que Nautilus Terminal utilisait pour s'infiltrer dans Nautilus fait partie de celles supprimées sans aucun remplacement :

LocationWidgetProvider

The Nautilus.LocationWidgetProvider was removed without replacement. If your script requires it, you can request a new model-based API for your specific use case on the Nautilus issue tracker.

Après, il faut reconnaitre que Nautilus Terminal n'a jamais été un citoyen de première classe dans Nautilus. En fait, il n'aurait même jamais dû pouvoir exister : Nautilus n'a jamais fourni aucune API permettant d'intégrer proprement un Terminal.

Pour être clair, Nautilus Terminal se glissait par une fissure dans le mur, puis faisait péter toute l'interface avant de la reconstruire à sa sauce. Il y a littéralement une classe qui s'appelle Crowbar (pied de biche en anglais) dans le code ! Nautilus Terminal était donc rempli de bricolages pour réussir à contourner les limitations, et tout simplement pour fonctionner.

Ce projet m'a toujours posé de grandes difficultés à maintenir, et la moindre erreur pouvait rendre Nautilus instable (puisqu'on va fourrer ses pattes dans des trucs qu'on est pas censé toucher). Si vous voulez en apprendre plus à son sujet, et sur sa maintenance chaotique, je vous invite à lire l'article que je lui avais dédié en 2018 (assurément l'un des articles les plus « personnels » de ce blog) :

Nautilus Terminal, c'est donc terminé pour le moment. Peut-être qu'un jour Nautilus proposera de nouvelles APIs adaptées à l'intégration d'un terminal, et ce jour-là Nautilus Terminal renaîtra peut-être... Mais il faudra tout réécrire depuis zéro (ça ne fera jamais que la 4ème fois 😉️).

Je souhaite remercier tous les utilisateurs et les contributeurs qui ont soutenu le projet toutes ces années, on se reverra peut-être un jour ! 🙂️

Et FLOZz dans tout ça ?

J'ai énormément d'idées d'articles sur des sujets variés (du DevOps, du Python, du hacking, du Flipper Zero, et j'en passe), j'ai énormément d'idées d'améliorations pour mes projets en cours, et j'ai énormément d'idées de nouveaux projets... mais les journées ne faisant que 24h, le temps me manque.

J'ai l'impression d'avoir passé ces derniers mois dans un long tunnel, dans lequel j'ai enchaîné les développements sur mes projets à un rythme effréné sans jamais prendre le temps de faire de pauses. Et forcément, durant cette traversée, j'ai négligé pas mal de choses, comme ce blog, mais aussi mon équilibre personnel et mon bien-être.

Il est difficile de prendre du recul lorsque l'on court d'un projet à l'autre sans jamais s'arrêter, mais j'ai heureusement fini par me rendre compte de la situation avant qu'il ne soit trop tard. Je vais donc mettre le nez hors de ce tunnel infernal. Je ne peux plus m'infliger cette quantité de travail et toute cette pression : ce n'est pas sain.

Je vais dès à présent m'efforcer de ralentir la cadence et de prendre davantage de temps pour moi. Je ne vais bien sûr pas abandonner mon blog ni mes projets (je ne crois pas en être capable), mais je vais y aller à mon rythme, et je vais surtout arrêter de me culpabiliser quand les choses n'avancent pas assez vite à mon goût. Tout ceci doit rester une passion et pas devenir un second travail.

Je ne sais donc pas quand sortira le prochain article ni quand sortira la prochaine version de tel ou tel logiciel. Je peux juste vous dire que ça sortira quand ça sera prêt. 😉️

Illustration: un homme sort d'un tunnel sombre

J'espère que cet article ne vous aura pas semblé trop long ; je n'ai pas l'habitude de résumer des mois de travail en un seul article, il est donc fort possible que j'aie été trop bavard (il faut dire que l'écriture m'avait un peu manqué aussi). 😋️

N'hésitez pas à me donner votre avis ou à poser vos questions en commentaire ci-dessous ou par mail. À bientôt j'espère pour de nouveaux articles ! 😉️


L'image de couverture de l'article est un travail dérivé de la photo « Tunel pod Przełęczą Kowarską » de Paweł Opioła et est placée sous licence Creative Common BY-SA 4.0.