Haiku a 25 ans!

Le projet a démarré le 18 août 2001 avec l’ouverture d’une liste de diffusion et le premier fil de discussion « Ok, let's start » (Ok, allons-y). Le projet a été lancé suite à l’annonce de l’abandon de BeOS par Be, inc.

Depuis, le développement continue et plusieurs versions alpha et beta ont été publiées. Le système d’exploitation Haiku reprend les idées et l’architecture de BeOS, au point d’assurer la compatibilité binaire avec les applications existantes. Il modernise l’architecture du système et apporte de nombreux perfectionnements et améliorations, tout en restant dans l’esprit original.

L’objectif est de fournir un système pour l’informatique personnelle, facile à utiliser, léger et performant mais sans faire de compromis sur les fonctionnalités avancées.

Ce trimestre, les grosses nouveautés sont l’arrivée de la virtualisation avec NVMM, et les préparatifs pour la version beta 6 qui arrive bientôt!

Sommaire

• Virtualisation NVMM
• Applications
  • Tracker
  • DeskBar
  • HaikuDepot
  • SoftwareUpdater
  • Icon-O-Matic
  • ShowImage
  • ActivityMonitor
  • StyledEdit
  • WebPositive
  • TextSearch
  • Media Player
  • Cortex
  • Devices
  • Workspaces
  • DriveSetup
  • AboutSystem
  • OverlayImage
  • Préférences Bluetooth
• Outils en ligne de commande
• Kits
  • Interface kit
  • Package kit
  • Support kit
  • Network kit
  • Media kit
• Serveurs
  • app_server
  • Print server
  • Net server
  • Bluetooth server
  • Power daemon
• Systèmes de fichiers
• Pilotes matériels
  • Péripéhriques HID
  • Supports de stockage
  • Bluetooth
  • Réseau
  • Cartes graphiques
  • ACPI
  • HDA Audio
  • PCI
• libroot
• Noyau
  • Options du noyau et des drivers
  • Gestion du stockage et des systèmes de fichiers
  • Gestion de la mémoire
  • Gestion des évènements
  • Ordonnanceur
  • Processeurs x86
• Bootloader
• Outils de compilation
• Documentation
  • Documentation interne
  • Haiku Book
• ARM & RISC-V
• Et alors, ça vient, cette bêta 6 ?

Ce rapport correspond aux changements effectués en mai, juin et juillet 2026 : il s’agit des révisions hrev59672 à hrev59921 du code source.

Entre parenthèses à la fin de chaque note, le pseudonyme de la personne qui a effectué le changement. Certains développeurs contribuent uniquement sous pseudonymes, d’autres utilisent leur nom légal, mais par habitude c’est le pseudonyme qui est utilisé par défaut.

Virtualisation NVMM

Le portage de NVMM (le virtualiseur de NetBSD) réalisé par DalmeGNU pendant le Google Summer of Code 2024 a été mergé. Cela permet en principe de lancer des machines virtuelles (avec QEMU) bénéficiant de l’accélération matérielle du CPU, et donc avec de bonnes performances.

Le code est intégré dans la branche principale des sources de Haiku et sera disponible dans la bêta 6, avec tous les changements dans le noyau (y compris quelques fonctionnalités supplémentaires et un certain nombre de corrections de bugs). Waddlesplash a ajouté le code nécessaire pour les processeurs AMD (le projet GSoC s’était concentré sur les processeurs Intel), et a commencé à améliorer les performances (les premiers essais de virtualisation donnaient des résultats plus lents que l’émulation purement logicielle de QEMU).

La virtualisation semblait ne pas fonctionner, ni pour lancer Haiku ni diverses distributions Linux, ce qui semblait pointer vers un problème général dans le virtualiseur. Finalement, après investigation par SED4906, le problème déclenché par un système invité Haiku était en fait un bug n’ayant rien à voir avec la virtualisation. Des modifications sur le pilote VESA pour implémenter le « live patching » et l’injection de modes vidéo supplémentaire dans le BIOS des cartes graphiques essayait de copier une zone de mémoire physique dans laquelle il n’y a rien. Cela ne pose pas problème sur une vraie machine, mais déclenche une erreur de NVMM (PulkoMandy).

Les problèmes pour Linux et d’autres systèmes n’étaient pas liés, mais ont également pu être corrigés.

Une version de QEMU utilisant l’accélération NVMM est désormais disponible dans les dépôts de paquets. Cela fournit une solution pour lancer les logiciels pas encore portés vers Haiku, et facilite également le développement de Haiku en auto-hébergé sans avoir à constamment redémarrer la machine pour lancer une version de test du noyau.

Applications

Correction de plusieurs problèmes de messages et textes impossibles à traduire suite à de mauvaises utilisations des API d’internationalisation (Madmax).

Tracker

Tracker est le navigateur de fichiers de Haiku. Il est basé sur les sources du Tracker original de BeOS avec de très nombreuses améliorations. Le code est un peu daté et fait l’objet depuis plusieurs années d’un gros travail d’amélioration et de nettoyage.

jscipione poursuit les améliorations du Tracker:

• Correction de régressions sur la position du défilement lorsqu’on passe d’un répertoire à l’autre.
• Glisser-déposer d’un fichier sur un autre fichier (par exemple pour l’ouvrir dans une application).
• Correction d’un bug d’affichage lors du glisser-déposer entre fenêtres du Tracker dont les icônes ne sont pas de la même taille.
• Retour en arrière sur une modification de l’affichage du « drag bitmap » pour en limiter la taille (sinon l’affichage est trop lent et consomme beaucoup de CPU).
• Encore des corrections sur l’affichage de la poubelle (icône qui doit changer selon qu’il y a des fichiers ou pas dans la poubelle) sur le bureau et dans les panneaux de navigation Ouvrir/Enregistrer.
• Correction de problèmes de glisser-déplacer dans la fenêtre “racine” et désactivation du menu de choix des disques dans les panneaux d’enregistrement et ouverture de fichiers.

Traduction du nom de la poubelle lorsque l’option pour traduire les noms des dossiers système est active (humdinger).

Correction de plantage (récursion infinie) dans du code de debug (non activé par défaut, même dans les versions “nightly” de Haiku, donc cela ne concerne que les développeurs) (PulkoMandy).

Correction de problèmes de synchronisation entre threads dans BFilePanel qui cassaient parfois la mise en page de la fenêtre (des boutons et champs de texte se retrouvant en dessous d’autres contrôles ou en dehors de la partie visible de la fenêtre) (PulkoMandy et waddlesplash).

Amélioration du placement des noms de fichiers édités (lors d’un renommage) et de la zone de sélection tracée autour (k32n13).

Correction d’un problème d’affichage du nombre d’éléments dans les dossiers ainsi que de la fenêtre d’informations détaillées sur les fichiers (Madmax).

DeskBar

DeskBar est la barre des tâches, également récupérée des sources de BeOS et grandement améliorée. Elle est cependant plus simple que le Tracker et ne nécessite pas autant de maintenance.

Petite amélioration de la fenêtre permettant de configurer le nombre d’éléments “récents” à afficher dans la DeskBar (jscipione).

HaikuDepot

HaikuDepot est le gestionnaire de paquets et magasin d’applications de Haiku. Il permet de découvrir et d’installer des logiciels, de les évaluer et de laisser des commentaires.

apl continue le développement de HaikuDepot avec ce mois-ci :

• Régression déclenchant un crash lors de l’ouverture de fichiers hpkg.
• Simplification des vues “indisponibles” (par exemple si un paquet n’a aucune revue par les utilisateurs, ou pas de capture d’écran disponible).
• Amélioration de la sélection de paquets dans la liste (pour pouvoir installer ou désinstaller plusieurs paquets d’un coup).
• Amélioration de la navigation au clavier.
• La fenêtre demandant l’autorisation d’envoyer des statistiques anonymes a le bouton “refuser” activé par défaut.
• Vérification que la date du système est assez proche de celle du serveur (nécessaire pour éviter des problèmes de connexion SSL pour cause de certificat apparemment expiré).
• Désélection des paquets dans la liste des résultats lorsqu’ils sont cachés par un filtre de recherche.

SoftwareUpdater

SoftwareUpdater permet de lancer les mises à jour du système et des paquets installés.

Au trimestre dernier, une option pour supprimer automatiquement les points de restauration anciens a été ajoutée. Elle a été renommée avec un label moins technique et plus facile à comprendre (humdinger).

L’option « afficher plus de détails » a été déplacée de la fenêtre principale vers la fenêtre de réglages (humdinger).

Icon-O-Matic

Icon-O-Matic permet d’éditer des icônes au format vectoriel HVIF. Ce format très compact permet de stocker les icônes dans l’espace disponible dans l’inode de chaque fichier, permettant un accès très rapide par Tracker et les autres applications ayant besoin d’afficher des fichiers avec leur icône.

Correction d’un crash (Zardshard).

ShowImage

ShowImage est un visualiseur d’images.

La barre d’outils était partiellement en dehors de l’écran lors de l’affichage en mode plein écran (nipos).

ActivityMonitor

ActivityMonitor permet d’afficher des graphes de charge CPU, température des composants, utilisation mémoire, et toutes sortes de statistiques de la machine.

Amélioration du calcul de taille minimale de la fenêtre (nipos).

StyledEdit

StyledEdit est un éditeur de texte. Il permet d’utiliser du formatage qui est enregistré dans les attributs étendus des fichiers texte, ainsi le contenu peut toujours être manipulé par des outils manipulant du texte.

Amélioration des menus pour configurer le style de texte : choix de couleurs, séparation des menus pour les polices de caractères et les styles (gras, très gras, fin, etc) pour éviter d’avoir un menu avec plusieurs douzaines de variations, peu pratique à naviguer (humdinger).

WebPositive

WebPositive est le navigateur web de Haiku. Il utilise le moteur WebKit, co-développé par Apple, Sony et Igalia.

Les URLs utilisées pour faire des recherches Google et DuckDuckGo sont maintenant les versions « no-AI » désactivant les résultats générés par LLM (nephele).

Correction du dimensionnement des boutons de la barre d’adresse et des onglets pour les écrans à très haute densité de pixels (nephele, PulkoMandy). Mise à l’échelle du bouton pour fermer la barre de recherche (Madmax).

Lorsque WebPositive est ouvert en cliquant sur un lien dans une autre application, correction d’un bug qui pouvait aboutir à ouvrir un onglet supplémentaire avec la page d’accueil par défaut, en plus du lien cliqué (nipos).

Suppression du code inutilisé qui implémentait un prototype d’interface à base de menu hamburger. Amélioration de la barre d’adresse : meilleure gestion du cas d’une barre d’adresse vide, et de l’apparence du bouton “Go” (nephele).

TextSearch

Textsearch permet de faire des recherches dans le contenu de fichiers avec des expressions régulières. Il s’agit d’un équivalent graphique de grep.

Le menu affichant l’historique des recherches tronque les textes très longs, pour éviter d’avoir un menu plus large que l’écran (humdinger).

Media Player

Media Player est un lecteur de fichier multimédia (son et vidéo).

Correction d’un bug empêchant de lire des vidéos en boucle (x512)

Cortex

Cortex est un gestionnaire d’application média, permettant de router la sortie d’une application dans l’entrée d’une autre et de manipuler les flux audio et vidéo de toutes sortes de façons intéressantes.

Retrait d’un contournement de bug de BeOS (plus nécessaire pour Haiku) et correction du gel de l’application lors de la suppression de nœuds média (x512).

Devices

L'application Devices affiche la liste des périphériques matériels de la machine.

Aquamatic est en train de travailler sur cette application dans le cadre du Google Summer of Code. Voir son article de blog pour tous les détails.

• Affichage du pilote utilisé et du chemin du périphérique publié dans /dev
• Amélioration de la disposition des éléments dans la fenêtre
• Affichage détaillé des descripteurs USB et décodage des descripteurs HID
• Affichage des périphériques Bluetooth

Changements de quelques textes dans l’interface pour rendre les choses plus claires et utiliser le vocabulaire en usage dans le reste du système (humdinger).

Mise à jour des listes d’identifiants PNP et ACPI avec les dernières versions disponibles (PulkoMandy).

Workspaces

Workspaces permet de visualiser les différents bureaux virtuels et de plus facilement naviguer entre eux.

Amélioration du texte de quelques éléments de l’interface pour les rendre plus compréhensibles et pour la cohérence du style d’écriture avec le reste du système (humdinger).

DriveSetup

DriveSetup permet de modifier la table de partition et de formater des partitions disque.

Il est maintenant possible de modifier le type de partition d’une partition existante, étape nécessaire pour une installation de Haiku en réutilisant une partition existante dédiée auparavant à un autre système (Nathan242).

AboutSystem

Aboutsystem affiche quelques infos sur la machine, sur la version de Haiku installée, ainsi que les noms de tous les développeurs ayant participé au projet et les mentions légales obligatoires.

Mise à jour de la liste des participants au projet : ajout de plusieurs participants au Google Summer of Code qui avaient été oubliés, et déplacement de Philippe Houdoin de la section « ancien développeurs » vers « développeurs actifs » puisqu’il est de retour (PulkoMandy).

OverlayImage

OverlayImage permet de placer une image en sur-impression sur le bureau ou dans tout autre endroit pouvant accueillir des _réplicants (NdM: leur faire passer le test Voight-Kampff ? Le terme est utilisé dans toutes les dernières nouvelles Haiku mais pas défini ou explicite. Pour vous appâter vers la documentation, sachez que c’est le nouvel ActiveX)._

Correction d’un crash (Waddlesplash).

Préférences Bluetooth

La fenêtre de préférences permettant de configurer le Bluetooth. Vous aviez deviné.

Mise en conformité du texte de l’interface graphique avec les règles de style (humdinger).

Outils en ligne de commande

Mise à jour de la base de données des IDs USB, et ajout du décodage des descripteurs CDC-NCM dans listusb (PulkoMandy).

Dans l’outil “workspaces”, ajout d’options pour se déplacer “géographiquement” (vers le haut, à droite, à gauche…) entre les espaces de travail. Ces paramètres peuvent être utilisés pour définir des raccourcis claviers personnalisés (korli).

Kits

Haiku offre une API assez complète aux développeurs d’application en C++. Cette API est découpée en “kits” qui regroupe des grandes catégories de fonctionnalités. Certains de ces kits sont dans des bibliothèques séparées, d’autres sont trop interdépendants et donc liés ensemble dans la bibliothèque libbe.so.

Interface kit

L'interface kit regroupe toutes les fonctionnalités liées à l’utilisation d’interface graphiques : fenêtres, vues, contrôles standardisés, pointeurs de souris…

Correction de plusieurs bugs lié au « mouse tracking » dans BListView, par exemple des changements de sélection inattendus (X512).

Une régression dans BTab:: SetEnabled empêchait de désactiver un onglet avant de l’attacher à une BTabView (waddlesplash).

Ajout de l’espace de couleur RGB 30 bit, utilisé par certaines machines Apple (smrobtzz).

Correction de problèmes de curseur invisible, mauvais affichage des marges, et utilisation systématique des tailles de polices de caractères mises en cache pour améliorer les performances dans BTextView (k32n13).

Correction d’un bug empêchant les raccourcis clavier de fonctionner lorsque la touche caps lock est active (Philippe Houdoin).

Correction d’un bug d’affichage des bordures des barres de progression avec le « control look » par défaut (Bill Hayden).

Package kit

Le Package Kit permet de manipuler les paquets logiciels et les dépôts permettant de les télécharger.

Correction d’une fuite mémoire dans la gestion des jobs du Package Kit (waddlesplash).

Support kit

Le support kit contient toutes les fonctions et structures de base indispensables: gestion des chaînes de caractères, listes, maps, et autres conteneurs utiles à toutes les applications.

Correction de l’échappement des chaînes de caractères lors de la conversion d’un BMessage en fichier driver_settings. Ce problème empêchait d’enregistrer les paramètres des réseaux wifi dont le nom contenait un espace ou certains autres caractères spéciaux. Cependant, il reste d’autres problèmes qui empêchent la connexion wifi de s’établir automatiquement au démarrage (madmax).

Dans BStringList, ajout d’une variante de la fonction de tri Sort() utilisant une fonction utilisateur pour comparer les chaînes (par exemple pour faire un tri “naturel” de texte contenant des nombres) (korli).

Modification du code générant un nom de CPU standardisé à partir du CPUID (sur les plateformes x86) pour faire confiance au champ « brand string » lorsqu’il est disponible (KevinAdams).

Correction de bugs dans BBufferIO (korli).

Network kit

Le Network Kit regroupe toutes les fonctions permettant la communication en réseau : gestion des interfaces, ouverture de sockets, client HTTP, etc.

Correction d’un bug dans la comparaison d’objets BNetworkAddress de type AF_LINK (adresses MAC) (madmax).

Media kit

Le Media Kit permet de gérer les fichiers et les flux multimédia. Il traite principalement de l’audio et de la vidéo mais pourrait être étendu pour d’autres usages impliquant des flux de données temps réel.

Correction d’un crash dans le code de conversion d’espace de couleurs pour la lecture de vidéos (PulkoMandy).

Serveurs

Les “serveurs” sont des applications système complétant le fonctionnement des kits. Ils sont l’équivalent des démons ou des services UNIX.

app_server

app_server est le serveur graphique se chargeant de l’affichage des applications à l’écran.

Refonte de la façon dont les configurations d’écrans sont enregistrées dans app_server, de façon à restaurer la bonne résolution d’écran en cas de crash d’une application qui avait changé la résolution de façon temporaire (par exemple un jeu lancé en plein écran avec une résolution spécifique) (waddlesplash).

Ajout de code pour une meilleure gestion des curseurs de souris accélérés par le matériel : sur les anciennes cartes graphiques, seul un curseur à 2 bits est disponible (pixels noir, blancs, transparents, ou inversés par rapport à ce qui est en dessous). Certains pilotes n’implémentent l’accélération que pour ce type de curseur, mais les curseurs utilisés par Haiku sont plus perfectionnés (niveaux de gris et canal apha). Dans ce cas, app_server peut convertir le curseur dans le format supporté par le pilote et la carte graphique (PulkoMandy).

Correction de problème d’accès au « frame buffer » pour afficher le curseur pendant un changement de mode écran. Cela corrige un plantage dans le cas où on change de résolution d’écran et qu’on déplace la souris en même temps (waddlesplash).

Correction de l’affichage du dernier pixel lors de l’affichage d’un bitmap avec un redimensionnement à filtrage bilinéaire (madmax).

Correction d’une inversion de verrous dans le code de gestion des curseurs de souris (Waddlesplash).

Sauvegarde des réglages de luminosité de l’écran même si le fichier de préférences des espaces de travail n’existe pas (PulkoMandy).

Print server

Le print server se charge de tout ce qui concerne les imprimantes et les impressions.

Suppression de l’imprimante « Enregistrer en PDF » installée par défaut, car elle ne fonctionne pas si le paquet « PDF Writer » n’est pas installé. Cette imprimante peut être configurée automatiquement lors de l’installation du paquet (KevinAdams05).

Ajout d’un test d’existence des add-ons d’impression avant de les charger. Auparavant, le serveur d’impression appelait load_add_on sans vérifier au préalable l’existence du fichier, puis détectait l’échec de cet appel. Ce qui fonctionne bien, mais émet un message dans le syslog pour indiquer une erreur de chargement. Cette erreur pouvait perturber certains utilisateurs (Philippe Houdoin).

Net server

net server est responsable de toutes les opérations concernant le réseau : configuration des interfaces, obtention et renouvellement des baux DHCP par exemple.

Correction d’un plantage lors du chargement d’un fichier network_settings ne comportant aucune option, ce qui peut arriver si on efface la configuration de tous les réseaux connus (madmax).

Bluetooth server

Le serveur Bluetooth se charge de la découverte et de l’appairage des périphériques Bluetooth.

Mohapped R. Attia est en train d’implémenter diverses fonctions et commandes Bluetooth dans le cadre du GSoC 2026.

Madmax a quant à lui corrigé un crash dans la fenêtre de préférences du Bluetooth et plusieurs dans le serveur.

Power daemon

Le power daemon est responsable de toutes les tâches liées à la gestion de l’énergie : déclenchement d’évènements lorsque la machine est connectée ou déconnectée du secteur, choix de l’algorithme d’ordonnancement à haute performance ou du mode économique. Il s’occupera plus tard de la mise en veille et de la remise en route du système.

Surveillance du statut de acpi_ac pour déterminer si la machine est reliée à une alimentation électrique, plutôt que de se baser sur l’état de charge ou décharge de la batterie (korli).

Systèmes de fichiers

Haiku implémente de nombreux systèmes de fichiers permettant l’interopérabilité et l’échange de données avec d’autres systèmes. Le système de fichier natif et indispensable pour installer Haiku est BFS, hérité de BeOS et qui a la particularité de pouvoir requêter les fichiers à partir d’attributs étendus indexés, à la façon d’une base de données.

Envoi d’une notification « node monitor » (équivalent de inotify sous Linux) lorsqu’un fichier est vidé par l’utilisation de O_TRUNC (nathan242).

Correction de plantages de BFS (jessicah):

• lors de la création d’un volume (formatage d’un disque) sans index d’attributs,
• lors de l’exécution de checkfs sur un volume sans index d’attributs.

Dans BFS également, mise à jour des dates de modifications remontées par stat lorsqu’un fichier est tronqué ou redimensionné. Le comportement n’était pas celui demandé par POSIX et cela causait par exemple des recompilations inutiles lors de l’utilisation de ninja (waddlesplash).

Correction du code permettant de déplacer ou de renommer des fichiers au travers d’un bindfs. Le code existant n’a jamais pu fonctionner, et n’a probablement jamais été utilisé ou testé (waddlesplash).

La troncation d’un fichier (suppression de tout le contenu) ne mettait pas à jour la date de modification si le fichier était stocké dans un ramfs (waddlesplash).

Correction de bugs dans les comparaisons de dates et d’une mauvaise gestion des erreurs dans le pilote NFSv4 (kallisti5).

Lors de l’initialisation d’un disque avec une table de partition Intel, effacement de quelques secteurs supplémentaires pour ne pas laisser un éventuel en-tête ISO9660 sur le disque (Nathan242).

Calcul de l’espace libre sur les disques btrfs (Abdullah Zulfiqar).

Pilotes matériels

Péripéhriques HID

Correction d’un plantage dans le pilote I2C HID sur certains appareils. Le pilote n’est toujours pas fonctionnel et reste désactivé par défaut (PulkoMandy).

Supports de stockage

Poursuite du travail sur les supports de stockage MMC et eMMC, avec l’implémentation d’une partie de la séquence d’initialisation pour ces cartes. Le pilote n’est pas fonctionnel pour ces cartes, l’initialisation n’aboutit pas. Il est par contre utilisable pour les cartes SD et SDHC (PulkoMandy).

Correction de bugs pour les périphériques de stockage USB présentant plusieurs “LUNs” SCSI, par exemple les lecteurs multi-cartes (SD, compact flash…) et la gestion de l’absence de média. Cela corrige en particulier un crash lorsqu’on débranche un tel lecteur du port USB (waddlesplash).

Bluetooth

Traitement de plus d’informations sur les périphériques Bluetooth dans le serveur Bluetooth pour affichage dans les résultats de scan (shivamsinghydv).

Vighnesh Sawant travaille sur le support des périphériques Bluetooth audio dans le cadre du GSoC 2026:

• Début d’implémentation des transferts isochrones
• Gestion des connexions de type SCO

Mohammed R. Attia travaille, également dans le cadre du GSoC 2026, sur les périphériques Bluetooth HID:

• Implémentation de l’appairage.

Correction d’une mauvaise utilisation de macros de manipulation de bits dans le pilote Bluetooth USB (korli).

Réseau

Intégration du pilote FreeBSD urtw (nommé realtekwifi8187 pour Haiku), ce qui permet d’utiliser certaines anciennes clés USB Wifi de chez Realtek (nathan242).

Ajout de nouveaux descripteurs et constantes dans les en-têtes liés à l’Ethernet par USB, en préparation pour l’intégration du pilote NCM. Encore un nouveau protocole standard pour l’Ethernet par USB, qui vient se placer aux côtés de ECM et RNDIS (PulkoMandy).

Nettoyage et correction de petits problèmes dans le pilote usb_rndis (PulkoMandy).

Remplacement des listes chaînées utilisées dans la pile réseau par une implémentation plus récente déjà utilisée dans d’autres composants. Cela permet de bénéficier d’assertions vérifiant que la liste n’est pas corrompue, et le code est inliné pour de meilleures performances (waddlesplash).

Correction d’un problème dans l’implémentation des sockets UNIX qui causaient un blocage lors de tentatives d’écrire plus de données que le tampon mémoire du socket ne peut en contenir (waddlesplash).

Cartes graphiques

Désactivation du “tiling” du framebuffer qui est activé par défaut par le BIOS sur certaines machines. Le pilote de Haiku a besoin d’un framebuffer linéaire, mais ne faisait pas la réinitialisation nécessaire de la configuration (smrobtzz).

Correction d’une régression dans le pilote VESA : les changements de mode vidéo n’étaient pas pris en compte par la console du débugger noyau, conduisant à un affichage illisible (Waddlesplash).

Ajout des identifiants PCI de quelques cartes graphiques Intel de la génération “Skylake” dans le pilote correspondant (KevinAdams05) et dans le pilote intel_gart (Waddlesplash).

Corrections du pilote pour les cartes graphiques S3 pour être compatible avec les machines 64 bit. Cette configuration est anachronique, mais réalisable (certaines cartes mères supportent à la fois un processeur 64 bit et un port PCI, ou bien il existe toutes sortes d’adaptateurs). Le bon fonctionnement de ce pilote ayant pu être confirmé, il est maintenant inclus dans la version 64 bit de Haiku (waddlesplash).

ACPI

Correction de problèmes d’ordonnancement dans l’initialisation de ACPI, ce qui a corrigé l’appel de méthodes ACPI (lecture de l’état de la batterie, arrêt de la machine…) sur plusieurs machines affectées par le problème (smrobtzz).

Réorganisation du code d’initialisation pour éviter une dépendance circulaire entre les pilotes ACPI et PCI (chacun ayant besoin de l’autre à différentes étapes dans l’initialisation) (smrobtzz). Ajout d’assertions pour s’assurer que le problème ne se reproduit pas, car il était particulièrement complexe à investiguer, avec un crash se produisant uniquement à l’arrêt de la machine alors que le problème était au démarrage (waddlesplash).

Correction du fonctionnement de read pour les pilotes acpi_lid et acpi_ac, et ajout d’une implémentation de select pour acpi_ac (korli).

HDA Audio

Tentative d’implémentation de l’envoi du son vers les ports HDMI de la carte graphique. Le code fonctionne pour le HDMI, mais ne fonctionne plus pour les sorties analogiques, il a donc été désactivé pour l’instant (x512).

PCI

Déplacement du code traitant l’espace I/O du driver générique vers le driver spécifique pour x86. La notion d’espace dédié aux entrées-sorties avec des instructions assembleur spécifiques pour y accéder n’existe sur aucune autre famille de CPU actuelle (smrobtzz).

libroot

La libroot implémente les fonctions standard C et POSIX ainsi que quelques extensions spécifiques à BeOS ou à Haiku. Elle est complétée par les libbsd et libgnu qui complètent cette API avec des extensions communes disponibles dans les systèmes BSD et dans la glibc, respectivement.

Ajout des définitions liés à la visibilité des symboles dans elf.h (jessicah).

Retrait d’en-têtes non-standard obsolètes (par exemple: null.h), déplacement des définitions aux bons endroits dans les en-têtes standards, correction de la définition de SIZE_MAX pour être du type size_t, divers autres nettoyages (waddlesplash).

Augmentation de la valeur de PTHREADS_KEYS_MAX à 512 pour pouvoir lancer les versions actuelles de Rust qui nécessitent beaucoup de clés TLS. Des changements similaires ont été faits par FreeBSD et OpenBSD, en attendant une éventuelle correction du problème du côté de Rust (PulkoMandy).

Correction du chemin d’accès à un fichier de configuration du résolveur DNS pour pointer vers un dossier accessible en écriture par l’utilisateur (Philippe Houdoin).

Mise en conformité POSIX des définitions de fonctions et types pour les caractères larges wchar, et mise à jour des stubs de la libroot (korli).

Ajout d’un cache stockant en espace utilisateur les informations sur les areas utilisées par l’allocateur mémoire malloc. Cela évite de faire un appel système pour retrouver cette information lors de l’appel à free (waddlesplash).

Mise en conformité POSIX de pthread_mutexattr_getprotocol (korli).

Noyau

Le noyau de Haiku est un noyau monolithique avec un système de modules, assez classique de nos jours. Il implémente des appels systèmes assez similaire à d’autres systèmes de la famille UNIX. Sa principale particularité est d’être implémenté en C++ comme le reste du système, ce qui améliore la lisibilité du code et les performances.

Autorisation d’une taille de pile jusqu’à 64MiB pour les threads utilisateurs, nécessaire pour le compilateur du langage Zig (ypsvlq).

Ajout d’une vérification de pointeur NULL manquante dans l’implémentation de ioctl qui permettait de faire planter le noyau (waddlesplash).

Correction d’un problème d’entrée dans le debugger noyau lorsque certains coeurs de CPU sont bloqués dans une boucle d’attente active et ne peuvent pas répondre au message « start KDL ». Dans ce cas, le debugger est tout de même démarré et un message d’avertissement indiquant qu’un coeur est toujours occupé s’affiche. Ceci devrait permettre d’investiguer certains cas où tout le système semble gelé. Nettoyage au passage de l’information sur le « dernier appelant » dans les spinlocks, qui n’était plus du tout en phase avec l’implémentation actuelle des spinlocks (waddlesplash).

Ajout de fonctions utilitaires pour la conversion entre UTF8 et UTF16, qui seront utilisées par les pilotes FAT et exFAT, car ces systèmes de fichiers stockent des noms de fichier en UTF16 qui doivent être convertis (jim906, jscipione).

Options du noyau et des drivers

Les fichiers driver_settings de 0 octet sont maintenant considérés comme valides et ne contenant aucune option. Ces fichiers (variante des fichiers ini) sont utilisés entre autres par le launch_daemon et les fichiers vides déclenchaient des erreurs inutiles (nathan242).

L’option « Don't call the BIOS » empêche effectivement d’appeler le BIOS. Jusqu’à présent, elle était présente dans le menu de démarrage mais ne servait à rien (Waddlesplash).

Correction d’un pointeur de cookie mal géré dans le device manager qui pouvait faire planter le noyau (waddlesplash).

Gestion du stockage et des systèmes de fichiers

Correction d’un bug très ancien où le renommage d’une partition n’était pas propagé partout dans le noyau, ce qui causait l’apparition de l’ancien nom à certains endroits (nathan242).

Correction d’un gros problème dans l’I/O scheduler qui pouvait aboutir à des corruptions de données, dans le cas où un système de fichier utilise des blocs plus petits que les blocs du support de stockage sous-jacent. Par exemple, dans le cas d’un système de fichiers BFS avec des blocs de 2K, stocké sur un disque utilisant des secteurs de 4K. Cette configuration est toutefois peu probable : d’une part parce que les disques avec des secteurs de 4K ne sont pas courants, et d’autre part parce que les systèmes de fichiers BFS sur des disques de grande capacité vont utiliser par défaut une taille de bloc plus large. Le cas qui a permis de détecter ce problème est l’utilisation d’un ram disk : dans ce cas, les blocs disque font nécessairement 4Ko (taille d’une page mémoire) et le disque est de relativement petite capacité (quelques gigaoctets au maximum) (nathan242).

Ajout d’un système de quotas pour la mise en cache des fichiers modifiés. Ceci évite de remplir toute la mémoire lors de l’écriture vers un périphérique lent (par exemple une clé USB). Cela permet de supprimer un contournement dans le Tracker (appel périodique à sync) et d’améliorer les performances (waddlesplash).

Gestion de la mémoire

Correction d’assertions incorrectes dans le traitement des pages de mémoire virtuelle, qui déclenchaient des kernel panic lorsque la mémoire est très sollicitée (waddlesplash).

Correction d’un interblocage dans les fonctions de gestion de la mémoire virtuelle pour gérer les permissions page par page (par exemple lors de l’utilisation de mprotect()). Au passage, correction de problèmes de performances et ajout d’assertions supplémentaires pour détecter d’autres cas inattendus. Ce qui a débouché sur la détection d’un autre problème qui n’est pas encore complètement identifié… (waddlesplash).

Correction d’une inversion de flags dans le code de verrouillage de la mémoire, qui déclenchait des fausses erreurs IO lorsqu’il restait trop peu de mémoire libre. Au passage, nettoyage du code et ajout d’assertions (waddlesplash).

Améliorations des commandes du debugger noyau pour investiguer l’allocateur “slab” et le tas gardé. Optimisation de l’allocateur d’espace d’adressage pour réduire encore un peu la consommation mémoire de Haiku et changement de constantes dans l’allocateur général (ces changements ne sont pas inclus dans la version beta 6, ils seront pour la prochaine car trop risqués) (waddlesplash).

Correction de l’utilisation d’une variable 32 bit pour gérer la mémoire libre sur les systèmes 32 bit, y compris lorsque PAE est actif et permet de disposer de plus de 4GB de mémoire libre au total (RAM physique ou swap) (waddlesplash).

Dans get_memory_map, correction d’un bug lorsqu’on demande à récupérer des informations pour une adresse qui n’est pas alignée sur le début d’une page. Cette fonction est utilisée entre autres dans les transferts DMA par les pilotes de stockage de masse. Dans ce cas, le bug peut apparaître seulement lors de combinaisons relativement inhabituelles de supports de stockage et de systèmes de fichiers. Cela l’a rendu assez difficile à identifier. La conséquence était une corruption de la mémoire du noyau, des crash à des endroits pas forcément directement liés, et cela seulement lorsque certaines options de debug (désactivées par défaut, y compris dans les nightly builds) étaient activées (waddlesplash).

Nettoyage du code de comptage des références dans VMArea (waddlesplash).

Gestion des évènements

Modification du comportement de select sur un descripteur de fichier FIFO pour ne pas remonter d’évènements qui n’ont pas de sens dans ce cas (Waddlesplash).

Améliorations de l’API event_queue et implémentation de EV_RECEIPT de façon compatible avec kqueue. Ajout dans kqueue de la possibilité de recevoir des évènements concernant les ports et sémaphores (extension par rapport à ce qui est disponible dans BSD) (waddlesplash).

Ordonnanceur

Ajout d’une assertion pour vérifier que le compteur « pinned to CPU » des threads n’est jamais négatif (waddlesplash).

Ajout de barrières mémoire manquantes dans les fonctions de “pinning” des threads, qui déclenchaient des kernel panics (rares) et d’autres problèmes (korli).

Ajout d’un mécanisme dans le scheduler pour interdire l’activation d’autres threads (nécessaire pour le virtualiseur NVMM) (waddlesplash).

Refonte de la gestion des verrous sur les « user timers », pour corriger des cas de gel complet du système mais aussi améliorer la performance et nettoyer le code : les verrous sont plus fins, il y a des assertions supplémentaires, et plein d’autres changements (waddlesplash).

Processeurs x86

Modifications dans la sauvegarde de l’état du FPU pour pouvoir utiliser AVX-512 sur les processeurs où il est disponible. Cela nécessite de réserver plus de place pour la sauvegarde des registres CPU lors des changements de contexte, puisque AVX-512 ajoute des registres supplémentaires (waddlesplash et trungnt2910).

Nettoyage de la gestion des timers spécifiques à un coeur de CPU pour x86 : moins de lectures de registres matériels, et ré-activation de certains cas d’optimisation qui permettent d’éviter une réinitialisation des timers (waddlesplash).

Suppression d’un branchement inutile dans le code de changement de contexte (SED4906).

Modification de l’initialisation pour que le raccourci clavier permettant d’accéder au débugger noyau soit disponible beaucoup plus tôt dans le démarrage du système (waddlesplash).

Bootloader

Le chargeur de démarrage fournit un menu permettant de configurer diverses options du système. Il est dérivé en plusieurs versions pour différentes interfaces avec le matériel : BIOS, PXE, EFI, OpenFirmware.

Ajout d’une vérification pour déclencher une erreur dès qu’il n’y a plus de place dans les structures de gestion de la mémoire. Ce cas n’était pas bien intercepté auparavant et causait des erreurs, voire des corruptions de mémoire plus tard dans le processus de démarrage, rendant les choses plus difficiles à investiguer (smrobtzz).

Correction de l’initialisation d’un registre de contrôle sur les processeurs x86 qui configure la gestion de la mémoire virtuelle (entre autres choses). Le chargeur de démarrage BIOS l’initialisait bien, mais le chargeur EFI ne l’initialisait que pour le premier cœur de CPU, laissant les autres dans un état indéterminé. Ce problème a été détecté par le code NVMM importé de NetBSD, qui refuse de s’initialiser si ce registre n’a pas une valeur cohérente. Mais cela corrige probablement d’autres problèmes jusqu’ici inexpliqués sur les machines démarrant en EFI (waddlesplash).

Outils de compilation

Haiku est compilé avec le compilateur gcc. Il utilise à la fois une version moderne et un fork de gcc 2.95.3, ce dernier permettant d’assurer la compatibilité avec BeOS. L’outil de compilation est Jam, un concurrent de make mieux adapté aux besoins d’un projet complexe comme Haiku.

Adaptations pour la sortie de gcc16 : reconnaissance de cette version lorsqu’elle est utilisée comme compilateur hôte (SED4906) et modifications de paramètres de compilation dans les scripts de gcc2 pour permettre de le compiler avec un compilateur moderne (en précisant qu’il est écrit en C89, qui n’est plus le standard par défaut dans la plupart des compilateurs) (waddlesplash).

Premiers ajouts dans le système de build pour prendre en considération l’existence d’une tentative de portage de Haiku sur l’architecture PowerPC 64 bits (SED4906).

Suppression de scripts de build inutilisés pour la gestion et la décompression de certains types d’archives (PulkoMandy).

Ajout de règles de détections des formats MS Office (docx, xlsx…) dans le renifleur de types MIME (Philippe Houdoin).

Ajout dans l’image de release d’un ensemble de sons à utiliser pour les diverses notifications du système (humdinger).

Documentation

La documentation est découpée en trois parties : un guide de l’utilisateur, un guide pour les développeurs d’applications (appelé « Haiku Book » en référence au « Be Book » qui remplissait le même rôle pour BeOS), et une documentation interne pour les développeurs souhaitant modifier Haiku lui-même.

Ajout d’un fichier AGENTS.md rappelant aux LLMs que leur utilisation est interdite avec Haiku et qu’ils doivent refuser de travailler (kallisti5, waddlesplash).

Documentation interne

Correction de fautes d’orthographe dans la documentation et grosse amélioration de la documentation des pilotes SD et MMC (PulkoMandy).

Correction de warnings levés par Sphinx lors de la génération de la documentation (PulkoMandy).

Ajout d’une page expliquant le fonctionnement des pilotes réseau et d’une autre sur les principes des pilotes de périphériques en général (PulkoMandy).

Ajout d’un pilote d’exemple pour le périphérique QEMU “edu” qui est justement prévu pour servir d’exemple et d’exercice (dridiha).

Haiku Book

Clarification de la documentation des valeurs de retour de BListView:: CurrentSelection (madmax).

Cafeina poursuit son travail pour compléter la documentation et couvrir tous les sujets:

• ajout du chapitre sur l’USB Kit,
• première partie de la documentation du Network Kit,
• ajout des fonctions du Kernel Kit concernant la gestion des “images” ELF chargées en mémoire (get_image_info et compagnie).

Correction d’une typo dans la documentation de BBufferIO (waddlesplash).

ARM & RISC-V

Actuellement, seuls les processeurs X86 (32 et 64 bits) sont officiellement supportés par Haiku. Le portage RISC-V est fonctionnel sur certaines machines mais pas au point de l’officialiser. Le portage ARM64 est en très bonne voie et commence également à être utilisable.

Quelques corrections simples pour les premières étapes du démarrage sur Raspberry Pi 5 (vous excitez pas trop, c’est encore très loin d’avoir une version fonctionnelle). En particulier, des améliorations sur le séquencement de démarrage des différents coeurs de processeur SMP (smrobtzz).

Quelques avancées également pour les machines Apple (smrobtzz).

Correction d’offsets dans le code de génération des images de carte SD et rétrogradation de la version de l’architecture ARMv8 nécessaire pour démarrer Haiku (kallisti5).

Et alors, ça vient, cette bêta 6 ?

La branche bêta va être créée fin juillet, avec un objectif de publication pour mi-août.

La phase de test a eu lieu durant le mois d’août, de nombreux petits problèmes ont été corrigés et la publication est toute proche. Bientôt une autre dépêche annonçant les nouveautés principales de cette version!

Dix-huit ans après ses débuts, G’MIC, cadriciel libre pour le traitement des images numériques, franchit une étape importante avec la sortie d'une nouvelle version majeure, numérotée 4.0, la version de la maturité !

L'occasion, comme chaque année, de faire le point sur les évolutions récentes de ce projet, depuis notre dernière dépêche publiée en août 2025.

N. D. A. : Cliquez sur les images pour en obtenir une version en pleine résolution, ou une vidéo correspondante lorsque les images contiennent l’icône 

Sommaire

• 1. G’MIC : Un cadriciel libre pour l'image numérique
• 2. Nouveaux filtres du greffon G'MIC-Qt
  • 2.1. Filtre « Rendering / Pixel Stretch »
  • 2.2. Filtre « Rendering / Gradients [Poles] »
  • 2.3. Filtre « Artistic / Marker Drawing »
  • 2.4. Filtre « Deformations / Heightfield Warp »
  • 2.5. Filtre « Degradations / Offset Stripes »
  • 2.6. Filtre « Colors / Transfer Colors [Multi] »
• 3. Nouveautés et améliorations du cœur du logiciel et de sa bibliothèque standard
• 4. Nouveau dépôt de codes sources: gmic-interactive-demos
  • 4.1. The SteamFace Machine
  • 4.2. Virtual Artist
  • 4.3. GREYC Warp
• 5 G'MIC et le code créatif
  • 5.1. Codes créatifs courts
  • 5.2. Continuation de la série « G'MIC Adventures »
• 6. Autres nouvelles liées au projet
• 7. Conclusion

1. G’MIC : Un cadriciel libre pour l'image numérique

Le projet G'MIC (GREYC's Magic for Image Computing) est né en juillet 2008, et a grandi au sein de l'équipe IMAGE du laboratoire GREYC de Caen (Unité Mixte de Recherche placée sous la triple tutelle du CNRS, de l'ENSICAEN et de l'Université de Caen).

Sa vocation : offrir un cadriciel libre, ouvert et extensible pour la manipulation, le traitement et la création d'images numériques. Pour ce faire, il s'appuie sur les fonctionnalités de la bibliothèque libre C++ de traitement d'images CImg, développée depuis 1999 d'abord au sein de l'INRIA, puis de l'équipe IMAGE du GREYC (également par votre serviteur).

Au cœur du projet se trouve un interpréteur de langage de script dédié, le « langage G'MIC », spécialement conçu pour prototyper rapidement de nouveaux algorithmes de traitement d'images, et les enchaîner au sein de pipelines (ou filtres) personnalisés. Autour de ce noyau viennent se greffer plusieurs interfaces, donnant à l'utilisateur accès à des centaines d'opérateurs de traitement d'images prédéfinis, comme par exemple l'outil en ligne de commande gmic ; le service Web G'MIC Online ; et le greffon G'MIC-Qt, qu'il est possible d'intégrer dans plusieurs logiciels de création et d'édition d'images, tels que GIMP, Krita, digiKam, Paint.net, Adobe Photoshop ou Affinity Photo. C'est aujourd'hui ce greffon qui est l'interface du projet la plus utilisée, avec plus de 1200 téléchargements quotidiens, en progression depuis un an. Il propose plus de 640 filtres variés pour triturer vos images et enrichir les possibilités des logiciels de retouche, et semble particulièrement apprécié des artistes numériques.

Cette version majeure 4.0 marque un tournant dans la vie du projet : la syntaxe du langage G'MIC, le code de l'interpréteur et des algorithmes de traitement d'images associés sont maintenant éprouvés. Nous souhaitons donc ralentir un peu le rythme des nouvelles releases et de l'ajout de nouvelles fonctionnalités, pour nous concentrer sur la stabilité, la robustesse, et les performances du cadriciel.

Fig. 1.1. Aperçu de quelques-unes des interfaces proposées par le projet G'MIC : Greffon G'MIC-Qt pour GIMP (en haut à gauche), Outil CLI gmic (en haut à droite), Service web G'MIC Online (en bas).

2. Nouveaux filtres du greffon G'MIC-Qt

Côté greffon G'MIC-Qt, l'essentiel des nouveautés se concentre sur l'apparition de nouveaux filtres de traitement d'images. La version 4.0 porte leur nombre à 644, tous accessibles directement depuis l'interface graphique. Je liste ci-dessous les derniers filtres ajoutés.

2.1. Filtre « Rendering / Pixel Stretch »

Le filtre « Rendering / Pixel Stretch » permet de sélectionner une « bande de pixels », et la duplique dans l'image en lui faisant suivre une trajectoire personnalisable, définie par deux courbes splines (une pour chaque bord de la bande).

Fig. 2.1.1. Le filtre « Rendering / Pixel Stretch » tel qu'il apparait dans le greffon G'MIC-Qt.

Fig. 2.1.2. Exemple de rendu du filtre « Rendering / Pixel Stretch », ici avec deux traînées de pixels ajoutées par le filtre.

Cet effet donne l'impression que l'image a été étirée localement, un peu comme une pâte élastique. Il peut servir à suggèrer ou styliser un mouvement dans une image, comme sur l'exemple ci-dessous (extrait de la vidéo tutorielle que Miguel Pineau a spécialement dédiée à ce filtre).
On peut également imaginer son utilisation pour du Glitch art ou de la création de textures abstraites.

Fig. 2.1.3. Le filtre « Rendering / Pixel Stretch » appliqué pour styliser le mouvement d'une danseuse (Crédits : Miguel Pineau).

2.2. Filtre « Rendering / Gradients [Poles] »

Toujours dans cette section « Rendering », notons l'arrivée de « Rendering / Gradients [Poles] », un filtre générant des dégradés de couleurs en interpolant spatialement des points-clés colorés, dont les positions et les couleurs sont laissées au choix de l'utilisateur. Ici, l'interpolation fait usage des fonctions de base radiale qui produisent des dégradés de couleurs lisses et harmonieux. L'utilisateur a également le choix de l'espace de couleurs dans lequel l'interpolation s'effectue. L'animation ci-dessous illustre le fonctionnement de ce filtre au sein du greffon.

Fig. 2.2.1. Le filtre « Rendering / Gradient [Poles] » crée des gradients spatiaux de couleurs possiblement complexes, à partir de quelques points de contrôle.

2.3. Filtre « Artistic / Marker Drawing »

Passons maintenant au filtre « Artistic / Marker Drawing », qui comme son nom l'indique, essaye de redessiner une image d'entrée sous la forme de traits de stylos feutres colorés. L'algorithme sous-jacent trace effectivement des splines colorées aléatoires sur une feuille blanche, le long des contours des structures géométriques présentes dans l'image à reproduire.

Fig. 2.3.1. Le filtre « Artistic / Marker Drawing » redessine une image en simulant l'utilisation de stylos feutres colorés.

Les nombreux paramètres réglables de ce filtre permettent d'obtenir des rendus potentiellement variés, plus ou moins abstraits, comme l'illustre la figure comparative suivante :

Fig. 2.3.2. Trois types de rendus du filtre « Artistic / Marker Drawing », utilisant trois jeux de paramètres différents.

2.4. Filtre « Deformations / Heightfield Warp »

Changeons maintenant de thématique avec le filtre « Deformations / Heightfield Warp » qui crée un effet 3D, en déformant une image d'entrée comme si elle était plaquée sur une carte d'élévation (définie de manière paramétrique). Un effet d'éclairage additionnel, de type ombrage de Phong, peut être activé pour accentuer davantage l'effet de volume 3D produit par ce filtre.

Fig. 2.4.1. Le filtre « Deformations / Heightfield Warp », tel qu'il apparait dans le greffon G'MIC-Qt, ici avec une élévation correspondant à une demi-sphère bombée vers la caméra.

Ce filtre est particulièrement flexible : il laisse la possibilité à l'utilisateur de définir explicitement des formules mathématiques personnalisées pour les cartes d'élévations. Les mathématiciens en herbe peuvent ainsi laisser libre cours à leur imagination pour déformer leurs images !

Fig. 2.4.2. Application de trois formules personnalisés de cartes d'élévations 3D, avec le filtre « Deformations / Heightfield Warp ».

2.5. Filtre « Degradations / Offset Stripes »

Les amateurs de Glitch art pourront être séduits par le nouveau filtre « Degradations / Offset Stripes », qui crée un effet de décalage de bandes d'images, horizontales et/ou verticales, avec des amplitudes de décalage aléatoires.

Fig. 2.5.1. Le filtre « Degradations / Offset Stripes » applique des décalages aléatoires sur des bandes d'images horizontales et/ou verticales.

Ce principe de base est tout simple, mais là encore, les nombreux paramètres du filtre donnent accès à des décalages décorrélés sur chaque canal, pour des espaces couleurs variés, en pouvant itérer ces décalages aléatoires, et autorisent ainsi une grande variété de dégradations d'images de type « Glitch », comme illustré sur la figure ci-dessous.

Fig. 2.5.2. Résultats de différents jeux de paramètres du filtre « Degradations / Offset Stripes », appliqués sur une même image de portrait.

2.6. Filtre « Colors / Transfer Colors [Multi] »

Et pour terminer ce résumé des nouveaux filtres du greffon G'MIC-Qt, j'ai gardé le plus intéressant pour la fin : le filtre « Colors / Transfer Colors [Multi] » est un nouveau filtre de transfert de couleurs entre deux images.

Le transfert de couleur consiste à appliquer une transformation couleur à une image « Source », en prenant comme référence une deuxième image (image dite de « Style ») dont on veut reproduire le style ou l'ambiance colorimétrique, et ceci bien sûr en préservant autant que possible les structures importantes (contours, objets, contenu sémantique) présentes dans l'image « Source » d'origine.

Fig. 2.6.1. Principe du transfert de couleur entre images: une image « _Source » (à gauche) est modifiée (à droite) de telle façon qu'elle « emprunte » les couleurs d'une image de « Style » (au centre)._

D'un point de vue algorithmique, il y a de nombreuses façons d'aborder ce type de transfert. Le filtre « Colors / Transfer Colors [Multi] », comme son nom le suggère, implémente trois méthodes différentes pour ce faire : une méthode ACP ; une méthode de transfert d'histogrammes ; et enfin une méthode variationnelle. Pour utiliser ce filtre dans le greffon G'MIC-Qt, il suffit de l'appeler sur une image contenant deux calques superposés : un calque contenant l'image « Source » à modifier, et un calque avec l'image « Style » contenant les couleurs de référence à transférer.

Fig. 2.6.2. Le filtre « Colors / Transfer Colors [Multi] » tel qu'il se présente dans le greffon G'MIC-Qt.

L'algorithme variationnel de transfert de couleur implémenté dans ce filtre est une production totalement originale : il est le fruit d'une collaboration de recherche entre deux membres de l'équipe IMAGE du laboratoire GREYC de Caen (D. Tschumperlé et J. Rabin), et d'une professeure du laboratoire de mathématiques LMI de l'INSA de Rouen (C. Le Guyader).

Bref, un algorithme 100 % normand, qui fonctionne forcément « vachement 🐄 bien » 😉, et que vous ne trouverez nulle part ailleurs !
On remercie chaleureusement la Fédération Normande de Recherche en Sciences et Technologies de l’Information et de la Communication (NormaSTIC) pour son aide financière qui a accéléré la mise en contact et le démarrage de cette collaboration fructueuse !

Notre méthode a plusieurs caractéristiques propres permettant de calculer des transferts de couleurs souvent pertinents, et de bonne qualité comparativement à ses concurrentes, et ce, de manière rapide et complètement automatique. La figure ci-dessous illustre des exemples de transferts de couleurs qu'il est possible d'obtenir pour une même image « Source », en choisissant des images de « Style » différentes (et en laissant les paramètres par défaut du filtre).

Fig. 2.6.3. Exemples de transferts de couleurs réalisés par le filtre « Colors / Transfer Colors [Multi] » sur une même image « Source », avec plusieurs images « Style » différentes.

La technique que nous proposons autorise également un mode « semi-supervisé » qui permet à l'utilisateur de forcer certaines correspondances de couleurs, et donc de « guider » l'algorithme pour calculer une solution de transfert plus contrainte et personnalisée.
Les deux exemples ci-dessous illustrent ce mode de contrôle de manière assez parlante :

Fig. 2.6.4. Guidage de l'algorithme de transfert de couleurs par mise en correspondance forcée de couleurs (Perruche → Mésange).

Ici, les plumes vertes du corps de la perruche (a) sont perceptuellement plus proches de la couleur jaune du corps de la mésange (b), et c'est donc cette mise en correspondance qui est réalisée par défaut par l'algorithme de transfert (résultat (c)). En explicitant des correspondances de couleurs souhaitées (liens symbolisés entre les images (a) et (b)), on peut modifier ce comportement et contraindre le transfert à assigner la couleur bleue de la mésange aux plumes de la perruche (résultat (d)).

Fig. 2.6.5. Guidage de l'algorithme de transfert de couleurs par mise en correspondance forcée de couleurs (Coccinelle → Formule 1).

Dans ce deuxième exemple, on note que la couleur rouge de la Coccinelle (a) se retrouve ailleurs dans l'image « Style » de la Formule 1 (b) : au bord de la route, sur les coquelicots… L'algorithme décide donc naturellement de conserver cette couleur quasiment telle quelle lors du transfert automatique (résultat (c)). Forcer des correspondances de couleurs explicites permet de guider l'algorithme pour lui faire changer la couleur de la Coccinelle en vert (résultat (d)).

Vous l'aurez compris, ce filtre représente l'aboutissement d'un travail de recherche de longue haleine en algorithmique du traitement d'images. Pour des chercheurs comme nous, il est réjouissant d'être arrivé au bout du processus complet : élaborer un nouvel algorithme complexe sur un bout de papier, le développer, l'implémenter, le peaufiner, en obtenir des résultats encourageants, le peaufiner encore et encore, en écrire une description détaillée dans un article scientifique (en cours de finalisation), l'intégrer proprement et le rendre utilisable par tout un chacun dans un logiciel libre, en sachant qu'il pourra être testé et utilisé potentiellement des milliers de fois !

Notons que ce n'est pas la première fois qu'une méthode de traitement d'images développée au sein de notre laboratoire de recherche se retrouve valorisée dans G'MIC. Cette page recense plusieurs publications scientifiques décrivant des algorithmes élaborés au sein de l'équipe IMAGE du GREYC, et qui sont accessibles comme filtres du greffon G'MIC-Qt.

3. Nouveautés et améliorations du cœur du logiciel et de sa bibliothèque standard

Comme évoqué précédemment, le terme G'MIC peut faire référence au langage de script du même nom. Ce langage est doté de son propre interpréteur et de sa bibliothèque standard de fonctions. Il est utilisé pour implémenter tous les filtres et opérateurs de traitement d'images mis à disposition des utilisateurs des différentes interfaces du projet.

Durant l'année écoulée, un grand nombre de petites améliorations ont été implémentées conjointement sur ce langage et sa bibliothèque standard.
En réalité, l'ensemble de ces contributions représente même la majorité du travail de développement réalisé, et en même temps ce sont des choses qu'il est difficile de valoriser dans une dépêche grand public : elles concernent principalement des points très précis et techniques du projet, comme par exemple des optimisations du parsing ou des algorithmes, du nettoyage de code, de nouvelles fonctions ou options pour l'évaluateur d'expressions mathématiques, etc.
Ce sont bien sûr des ajouts utiles pour les développeurs de nouveaux filtres dans ce langage, mais il est difficile de les mettre en valeur de manière réellement plaisante.

J'ai donc pris le parti de lister ci-dessous uniquement les quelques nouveautés facilement « illustrables » :

• La nouvelle commande random_patches réalise un rendu procédural d'images carrées contenant des formes géométriques et des textures synthétiques aléatoires. À quoi cela peut-il bien servir, me direz-vous ? Eh bien par exemple, à générer des ensembles d'images pour l'entrainement de réseaux de neurones convolutionnels, pour des tâches de débruitage et de super-résolution (ces réseaux sont ceux utilisés par les commandes denoise_cnn et scale2x_cnn).

Fig. 3.1. La commande random_patches synthétise des images carrées contenant des formes géométriques et des textures aléatoires.

Ces images sont en réalité suffisamment complexes pour qu'un réseau de neurones puisse apprendre des filtres convolutionnels pertinents pour l'analyse semi-locale de la géométrie des structures présentes dans des images plus naturelles. Ces filtres appris peuvent ensuite être utilisés dans des tâches de débruitage ou de super-résolution, qui sont des problèmes très géométriques et qui ne nécessitent pas vraiment une analyse sémantique du contenu des images. Utiliser ces données synthétiques pour entrainer des réseaux simples est donc largement suffisant pour ce type d'applications. D'une part, cela évite de stocker de grandes bases d'images volumineuses lors de l'entrainement (les images synthétiques étant générées à la volée). Et d'autre part, on évite automatiquement d'enfreindre le copyright éventuel des images présentes dans les ensembles d'apprentissage prédéfinis (dont la provenance n'est pas toujours clairement citée, avouons-le).

• La nouvelle commande shape_hilbert génère, comme son nom l'indique, une image de la courbe de Hilbert (en 2D).

Fig. 3.2. La commande shape_hilbert trace une courbe de Hilbert dans une image, commande illustrée ici avec des niveaux croissants de récursions.

• La nouvelle commande pca calcule une analyse en composantes principales (ACP) d'un ensemble de vecteurs. Ce type d'analyse permet à la fois de déterminer la dimensionnalité représentative de données vectorielles, ainsi que leurs orientations principales dans l'espace. L'ACP a de nombreuses applications en traitement d'images et plus généralement en analyse de données : débruitage, compression, reconnaissance de visages, analyse de textures, recalage géométrique, etc. L'exemple ci-dessous illustre son utilisation pour déterminer l'orientation des axes principaux (dessinés en pointillés) d'une silhouette de libellule.

Fig. 3.3. La commande pca est utilisée ici pour calculer les orientations des axes principaux d'une silhouette binaire 2D.

• Les nouvelles commandes depthmap3d et normalmap3d viennent enrichir les possibilités de rendus d'objets 3D maillés de G'MIC, en synthésisant des rendus d'un objet respectivement sous la forme de cartes de profondeurs et de normales 3D.

Fig. 3.4. Les commandes depthmap3d et normalmap3d appliquées sur un modèle 3D en rotation.

• Mentionnons enfin le travail d'amélioration général ciblé sur les algorithmes d'opérations matricielles présents dans G'MIC : arrivée de la décomposition QR (avec pivot), amélioration de la précision de calcul pour l'inversion de matrices et la résolution de systèmes linéaires… Et même s'il est difficile de rendre ça visuel, je vous propose cette petite ligne de commande qui crée une matrice carrée 40×40 aléatoire, qui l'inverse et qui calcule le produit des deux pour vérifier que l'on retrouve bien la matrice identité.

$ gmic 40,40 rand -1,1 +invert +mmul name A,invA,'A*invA'

Fig. 3.5. Exemple de l'utilisation de gmic en ligne de commande pour l'inversion d'une matrice aléatoire.

Tout ceci n'est bien sûr qu'un aperçu succinct de ce qui a été réalisé sur le cœur de G'MIC cette année. Pour plus de détails techniques, la consultation des Changelog est recommandée.

4. Nouveau dépôt de codes sources: gmic-interactive-demos

En tant que membre d'un laboratoire public de recherche, j'ai l'occasion de participer ponctuellement à des évènements de vulgarisation scientifique (tels que la Fête de la science, le FÉNO, etc.), où l'on présente certaines de nos activités de recherche au grand public (en algorithmique du traitement d'images en ce qui me concerne). Pour rendre ces présentations plus attractives et ludiques, j'ai élaboré au fil des ans, différents programmes et bornes de démonstration interactifs, en me reposant sur les possibilités offertes par le langage G'MIC.

Ces applications libres (sous licence CeCILL) sont maintenant accessibles sur ce dépôt logiciel : github.com/GreycLab/gmic-interactive-demos

Elles pourront intéresser des enseignants et/ou chercheurs souhaitant illustrer différents concepts du traitement d'images à des publics de néophytes. Ces codes illustrent aussi les capacités du langage G'MIC pour la création de programmes interactifs, et ceci indépendamment du greffon G'MIC-Qt.

Pour le moment, trois démonstrateurs sont présents dans ce dépôt logiciel. Ils sont détaillés ci-dessous.

4.1. The SteamFace Machine

« The SteamFace Machine » est le démonstrateur le plus récent. Il montre le fonctionnement des réseaux de neurones convolutionnels pour la détection d'un visage dans une image, et l'analyse de caractéristiques propres à ce visage, le tout enrobé dans un style SteamPunk du plus bel effet !

Fig. 4.1.1. Écran de lancement du démonstrateur « The SteamFace Machine ».

Le flux vidéo capturé par la webcam s'affiche à l'écran, et lorsqu'un visage est placé au centre de l'image, la jauge de détection faciale s'active. En bas à droite, on peut apercevoir la sortie de différentes couches intermédiaires du réseau de neurones réalisant la détection (classifieur binaire avec une architecture de type LeNet-5).

Fig. 4.1.2. Détection du visage par un réseau de neurones convolutionnel dans le démonstrateur « _The SteamFace Machine »._

Une fois la détection opérée, un deuxième réseau est inféré pour en extraire différentes caractéristiques faciales : genre, âge, type de cheveux, port de lunettes ou de chapeau, taille du nez…

Fig. 4.1.3. Analyse de quelques caractéristiques liées au visage détecté.

C'est une manière visuellement amusante de présenter le fonctionnement de classifieurs neuronaux au grand public, leurs capacités mais aussi leurs limites et les biais inhérents aux bases d'apprentissage utilisées pour les entrainer (dans le cas de ce démonstrateur, la base CelebA, qui contient des images assez éloignées de celles que l'on acquiert via la webcam dans un environnement non-contrôlé tel qu'un parc des expositions).

Mentionnons également la belle contribution de notre cher collègue Philippe Bernard, du service Administration système et réseaux du GREYC, qui a réalisé une borne physique de démonstration intégrant « The SteamFace Machine », facilement transportable à des évènements de médiation scientifique !

Fig. 4.1.4. Vidéo de démonstration de la borne « The SteamFace Machine » quand elle était en cours d'élaboration.

4.2. Virtual Artist

« Virtual Artist » est un deuxième démonstrateur interactif, qui cherche à illustrer le principe du « transfert de style » entre deux images.
Nous avons précédemment évoqué le transfert de couleurs (en section 2.6). Le transfert de style en est une extension naturelle : au lieu de transférer uniquement les couleurs, on cherche à transférer tout le style graphique d'une image « Style » vers l'image « Source ».
C'est bien sûr un problème autrement plus complexe, et les méthodes les plus performantes du domaine utilisent généralement de gros réseaux de neurones.

« Virtual Artist » n'a pas la prétention d'être à la pointe de l'état de l'art : c'est avant tout un démonstrateur pédagogique pour expliquer le principe général du transfert de style en traitement d'images. L'utilisateur peut jouer avec différentes images de « Source » et de « Style » prédéfinies. La figure ci-dessous illustre quelques-uns des écrans principaux de l'application.

Fig. 4.2.1. L'application « Virtual Artist » illustre le principe du transfert de style entre deux images.

Ce démonstrateur a été utilisé de nombreuses fois sur une grande table tactile, dans des évènements grand public, et fait toujours son petit effet !

Fig. 4.2.2. L'application « Virtual Artist » utilisée comme démonstrateur, ici au Festival de l'Excellence Normande (FÉNO) en 2021.

4.3. GREYC Warp

« GREYC Warp », le dernier démonstrateur de ce nouveau dépôt logiciel, implémente un miroir déformant interactif. L'utilisateur voit en direct le flux de la webcam et peut créer, déplacer ou supprimer des points clés qui définissent une déformation appliquée en temps réel. Une dizaine de transformations pré-définies sont également proposées.

Fig. 4.3.1. L'application « GREYC Warp » vous laisse déformer le flux vidéo de votre webcam, de manière interactive, et non sans humour !

Pour avoir testé ce démonstrateur en situation réelle lors d'expositions, ça fait beaucoup rire les enfants (mais pas les plus jeunes qui pensent que ça reflète vraiment l'apparence de leur tête et qui peuvent se mettre à pleurer). Une application toute simple mais néanmoins amusante !

5 G'MIC et le code créatif

Ces quelques démonstrateurs esquissent déjà l'image d'un langage G'MIC adapté au code créatif, qui consiste, selon Wikipedia, à « utiliser la programmation informatique comme un moyen d'expression artistique (visuel, musical, littéraire, interactif, performatif…) à part entière ».

5.1. Codes créatifs courts

En tant qu'ancien demomaker, le code créatif est forcément un domaine qui me tient à cœur, et j'écris et partage régulièrement des scripts courts sur le forum de G'MIC pour expérimenter de nouvelles idées d'effets graphiques, ou en reproduire certains sur lesquels je suis tombé et que je trouve captivants.
Quelques-uns de ces effets récents sont décrits ci-dessous, avec à chaque fois, un accès vers le code source correspondant (script .gmic).

• Agrégation limitée par diffusion tournoyante : Cet effet est une variante de l'agrégation limitée par diffusion, implémentant un système de particules en mouvement qui sont stoppées dès lors qu'elles rencontrent une masse d'éléments plus anciens, déjà immobiles. On ajoute à tout ça une rotation, un zoom inverse, une palette de couleurs, et le tour est joué ! Le code source de cet effet atteint difficilement les 36 lignes, commentaires inclus !

Fig. 5.1.1. L'effet animé « Agrégation limitée par diffusion tournoyante », rendu par G'MIC.

• Courbe de Hilbert néon : Cette animation stylise le dessin d'une courbe de Hilbert par un tracé incrémental faisant songer à un néon. Ici, le code source est beaucoup plus conséquent (52 lignes 😉).

Fig. 5.1.2. L'effet animé « Courbe de Hilbert néon », rendu par G'MIC.

• Morphing de formes : Ici, deux silhouettes se transforment l'une vers l'autre via un morphing continu. On utilise des edgels pour l'extraction et la paramétrisation du contour des deux silhouettes à transformer. Le code source de cet effet revient à un nombre de lignes de code quand même plus raisonnable que précédemment (36 lignes).

Fig. 5.1.3. L'effet animé « Morphing de formes », rendu par G'MIC.

• Tunnel 3D : Celui-ci est l'un de mes préférés. C'est certes un effet ultra-classique dans le monde de la scène démo, mais le rendu est sympa. Et avec ses 68 lignes, le code source pour générer cette animation de 256 frames (qui cyclent parfaitement) reste dans les limites du raisonnable !

Fig. 5.1.4. L'effet animé « Tunnel 3D », rendu par G'MIC.

• One-liner géométrique : Le langage G'MIC, grâce à sa syntaxe délibérément concise, est un candidat idéal pour la création de one-liners. Une section entière de la documentation de référence est d'ailleurs dédiée à quelques one-liners amusants. Étant tombé par hasard sur cette belle image créée avec GeoGebra par Georg Wengler, j'ai souhaité la retranscrire en langage G'MIC sous la forme d'une unique ligne de commande affichant une animation, et voici le résultat (et heureusement qu'une ligne de code ne se limite pas à 80 caractères !)

$ gmic 12,12,256,2,"a = 1 + x; b = 1 + y; t = lerp(0,2*pi*b,z/d); cos(a/b*t)*cexp([0,t])" 12,12,1,2,"S = crop(#-1,x,y,0,c,1,1,d#0,1); S = round(45*(S - avg(S)) + 50); draw(#-1,S,x,y,0,c,1,1,d#0,1)" rm. 1200,1200,1,3,255 repeat 256 { 12,12,1,1,"repeat (16,l, X = 100*[x,y] + round(I(#0,x,y,$> + l/16,2,2)); ellipse(#-1,X,1,1,0,1,0))" rm. +rs. 600 w. rm. wait 20 } rm

Fig. 5.1.5. L'effet animé « cos(ab) », rendu par G'MIC.

L'ensemble de ces nouvelles animations se retrouve dans la section Gallery du site web de G'MIC.

5.2. Continuation de la série « G'MIC Adventures »

De temps en temps, j'essaie aussi de partager l'ensemble du processus permettant d'arriver (en partant de zéro) à un résultat de code créatif.
Et cela, rédigé sous la forme d'un petit article partagé sur le forum de G'MIC. Cette série d'articles est nommée « G'MIC Adventures ». Je l'avais évoquée dans notre dernière dépêche. Deux nouveaux épisodes de cette série sont parus depuis :

• Apprentissage d'un perceptron multi-couches pour la reproduction d'une image couleur (G'MIC Adventure #5) :

Dans ce cinquième épisode, on cherche à entrainer un réseau de neurones simple (un perceptron multi-couches) capable d'apprendre une fonction image entière , c'est-à-dire un réseau capable de prédire une couleur correcte à partir d'un vecteur de coordonnées donné en entrée. Il est particulièrement intéressant de visualiser l'image couleur que le réseau est capable de reproduire à chaque itération de son apprentissage (figure ci-dessous), et ce, jusqu'à convergence.

Fig. 5.2.1. Reconstruction itérative d'une image couleur obtenue par l'apprentissage d'un perceptron multi-couches.

• S'amuser avec l'équation d'ondes (G'MIC Adventure #6) :

Dans ce sixième épisode, on s'intéresse à l'implémentation en G'MIC de l'équation d'ondes et ses possibilités pour appliquer des effets de déformations amusants sur des images, comme l'illustre la figure suivante qui correspond au résultat obtenu à la toute fin de l'article.

Fig. 5.2.2. Application d'une équation d'ondes anisotrope pour la déformation d'une image le long de ses contours.

Les exemples présentés dans cette section montrent que G'MIC a du potentiel pour le code créatif, notamment pour l'expérimentation rapide de codes d'effets graphiques. Le fait qu'il soit utilisable en ligne de commande (via la commande gmic) en fait un allié précieux pour générer des animations ou pour modifier des lots d'images de manière automatisée.

6. Autres nouvelles liées au projet

Pour finir cette longue dépêche, voici en vrac quelques autres nouvelles notables liées au projet :

• Diffusion de G'MIC : Avec le temps, la diffusion de G'MIC s'accélère et son installation se simplifie. Notons tout d'abord que G'MIC-Qt a été parmi les premiers greffons disponibles lors de la sortie de la version majeure 3.2 de GIMP. L'installation de ce greffon est maintenant aussi largement simplifiée pour les utilisateurs de macOS, grâce au travail remarquable des empaqueteurs de MacPorts, qui en proposent une version toujours très à jour.

Nous avons également appris que G'MIC suscite l'intérêt des projets suivants :

1. Le projet G'MIC-GEGL a pour objectif d'exposer les différents filtres du greffon G'MIC-Qt directement sous forme de nœuds GEGL, qui est la bibliothèque de traitement utilisée en interne dans GIMP. Cela voudrait dire que les effets de G'MIC-Qt pourraient à terme être utilisés dans des calques d'effets non-destructifs de GIMP.
2. Le projet PhotoFlare est un nouvel éditeur d'images numériques multi-plateformes, et son développeur a annoncé y avoir intégré le greffon G'MIC-Qt afin de profiter de ses centaines de filtres proposés.
3. Le projet gmic-affinity se propose de développer un greffon en Rust pour Affinity Photo, pour exposer le greffon G'MIC-Qt aux utilisateurs. Ce dernier est normalement déjà fonctionnel pour ce logiciel, via l'API 8bf (comme le montre cette vidéo), mais malheureusement pas encore pour les utilisateurs de macOS.
4. Enfin, notons l'arrivée de G'MIC-Qt sur le Snap Store, proposant ainsi une façon alternative d'installer notre greffon pour GIMP.

• Exposé : Début mai 2026, j'ai eu l'occasion de faire un bref passage au laboratoire LRDE de l'EPITA, sympathiquement invité par Marc Espie (enseignant et l'un des développeurs du projet OpenBSD), où j'ai donné une présentation intitulée « 25 ans de développement libre pour le traitement des images numériques ». Une vidéo de cette présentation a été captée et mise sur YouTube.

7. Conclusion

Cette version 4.0 marque un jalon important pour G'MIC : dix-huit ans après la première ligne de code, le projet a montré qu'un logiciel open-source né au sein d'un laboratoire de recherche public, et aux ressources modestes, peut s'installer durablement dans le paysage du graphisme numérique libre, et continuer à innover grâce à son écosystème ouvert et extensible.

Cette dépêche a cherché a montrer la maturité et la polyvalence de G'MIC. C'est un cadriciel multi-usages dont les interfaces variées peuvent toucher des publics différents, de l'artiste numérique au bidouilleur de la ligne de commande, en passant par le chercheur en traitement d'images, à partir du moment où une image numérique entre en jeu !

C'est aussi l'occasion de rappeler que rien de tout cela n'aurait été possible sans l'écosystème bienveillant qui gravite autour du projet. Nous tenons à remercier chaleureusement nos partenaires académiques (le CNRS, l'ENSICAEN, l'Université de Caen, la direction du GREYC), ainsi que l'ensemble de la communauté (testeurs, empaqueteurs, vidéastes et utilisateurs du quotidien). Votre soutien est très apprécié.

Les idées fourmillent, l'envie de triturer des pixels est toujours aussi présente, et on espère donc pouvoir continuer à développer et valoriser ce cadriciel libre comme il se doit dans le futur.

Y aura-t-il une nouvelle dépêche l'année prochaine ? L'avenir nous le dira !

Je travaille depuis plus de vingt ans sur site central (mainframe), et ça fait quasiment autant de temps que ma marotte, c'est me faciliter la vie au travail en automatisant le plus possible les actions répétitives.

Vous me direz rien de bien nouveau, c'est l'essence même de l'informatique…

Certes, mais je me rends compte qu'il existe tout un univers plutôt confidentiel à mon sens qui gravite autour l'aménagement de ses propres raccourcis clavier.

Sommaire

• Un peu d'historique
  • Problème de place
  • Le pad
  • Le cas Pacbase
  • L'invite de commande « universelle »
• Les logiciels de raccourcis sous Windows
  • Clavier+
  • AutoHotKey
  • Fonctionnalités communes
  • Ce qu'apporte AHK
• En résumé
• PS
  • Quelque raccourcis que j'utilise tout le temps
  • Tip

Un peu d'historique

Comme déjà écrit, je travaille sur site central, et pendant longtemps, ça voulait dire utiliser un émulateur 3270 (même si ça sert encore beaucoup pour les tâches d'administration, Eclipse et VSCode sont de plus en plus présents, notamment pour développer). C'est un logiciel qui simule un terminal passif (qui se contente d'afficher un écran, et de réagir au clavier, point barre - mais qui dispose du 24 touches fonction physiques), et qui dispose de fonctionnalités « modernes », tel le copier-coller (oui, oui, point de copier-coller sur terminal passif).
Ce qu'il y a de chouette avec un émulateur, et ça rejoint (enfin) le sujet de cette dépêche, c'est que ça permet de lancer des séquences de frappes de touche.

Prenons comme exemple l'affichage d'une table de paramétrage, pour afficher le contenu d'une table il faut :

• Appuyer sur la touche ECHAP (qui efface l'écran)
• Taper X RCD071
• Valider avec Enter
• Saisir le nom de la table de paramétrage
• Interroger son contenu avec PF3

L'émulateur permet de lancer des séquence de touches de plusieurs manières :

• à l'aide d'un raccourci clavier ;
• à l'aide d'un pad, ensemble paramétrables de boutons auxquels on peut associer des actions, dont une séquence de frappes de touche. C'est là que ça commence à devenir intéressant, je vais y revenir.

En reprenant l'exemple du listage d'une table de paramétrage, je peux facilement associer le listage de la table1 à un raccourci, et celui de la table2 à un autre.

Problème de place

Et c'est là qu'on s'aperçoit vite des limites des raccourcis claviers : leur nombre est forcément limité, d'autant plus que bon nombre de combinaisons sont déjà prises : il est illusoire de vouloir se passer de CTRl+C et de CTRL+V par exemple.
L'autre problème est celui de la mémoire, pas celle du PC, mais celle de celui ou celle qui est derrière le clavier : pas facile de mémoriser toutes ces combinaisons.

Le pad

J'ai gardé pour maintenant cette histoire de pad : mais qu'est-ce que ça apporte ? Et bien ça « libère » de la mémoire : la vocation du raccourci est disponible sous les yeux, et ça, j'achète !

Moyennant un petit travail de classification en sous-groupes, je retrouve facilement tous mes raccourcis en un clin d'œil.
Mais n'avoir à disposition que des boutons, est-ce suffisant ?
Pas vraiment, parce que libellé d'un bouton, c'est statique.

Le cas Pacbase

PACbase est un AGL (NdM: propriétaire) générant du COBOL, intégrant un dictionnaire de données. On y stocke :

• des données ;
• des structures de données ;
• des programmes ;
• des textes pour la documentation ;
• etc.

Ce qui est important pour le sujet que j'évoque que la navigation dans ce référentiel est entièrement textuelle, on accède aux entités au travers d'une ligne de commande :

• j'affiche la donnée toto en tapant E toto ;
• j'affiche la documentation de donnée toto en tapant e toto gc (ou si je suis déjà en train de consulter la donnée toto en tapant -gc) ;
• j'affiche un programme titi en tapant p titi, sa documentation en tapant p titi gc
• etc.

C'est là qu'on s'aperçoit de limite des boutons (même si c'est mieux que les raccourcis) : pas question de créer autant de boutons que d'entités à accéder.

L'invite de commande « universelle »

Il se trouve que l'interface principale du site central (hors applications métiers) qui s'appelle ISPF (NdM: propriétaire) est également textuelle est qu'elle possède également une ligne de commande.

J'ai donc cherché à mettre au point une interface dans laquelle je taperai mes commandes, qui seraient mémorisées et qui, à l'instar du comportement d'un terminal, faciliterait le rappel de commandes.

Au passage, j'ai écrit une macro « universelle » qui permet d'interagir de manière scriptée avec l'émulateur, en utilisant un pseudo langage très basique, mais permettant des actions reproductibles : saisie de paramétrage (permettant une « saisie » d'environnement en environnement), réinitialisation de mot de passe avec envoi de courriel avec les mots de passe provisoire, etc.

Je me suis appuyé sur différents modules proposés par l'émulateur 3270, avec comme limites l'univers site central. Or il se trouve que j'avais envie d'automatiser plein d'autres actions sur d'autres logiciels (comme lancer les règles dans Outlook par exemple).

Les logiciels de raccourcis sous Windows

Clavier+

C'est alors que j'ai découvert :

• Clavier+ (GPLv3), un logiciel libre qui a la bonne idée de pouvoir être lancé en ligne commande avec une documentation tout en français ;
• les pages HTA, qui sont des fenêtres écrites en HTML / Javascript / CSS.

J'écris mes pads en HTA, avec des liens qui lancent des actions via Clavier+. Et là, c'est quasi parfait : je paramètre Clavier+ pour lancer une fenêtre HTA quand je tape sur la touche PAUSE (facile d'accès et peu utilisée en standard) qui m'affiche des boutons d'actions et des invites de commandes, fenêtre qui se masque une fois l'action lancée et que je rappelle en rappuyant sur PAUSE. J'ai donc Clavier+ qui lance une fenêtre qui permet de lancer plein d'actions via Clavier+. Pas toujours facile de s'en sortir avec du Javascript pas toujours reconnu dans ses dernières fonctions pourtant bien pratique, et surtout, pas simple de gérer la persistance des données, même si je m'en suis sorti à l'aide de cookies.

AutoHotKey

Je change d'entité dans le groupe qui m'emploie, et patatras, pas de Clavier+ dans le centre logiciel ! Je me lance dans une demande d'intégration de Clavier+, demande qui traîne, et voilà que je découvre que si Clavier+ n'est pas proposé, c'est qu'à sa place figure AutoHotKey (GPLv2)

\o/ : apothéose : Autohotkey (AHK), c'est clavier+ puissance 1 000 ! Ça gère les raccourcis — heureusement —, mais aussi et surtout les interfaces graphiques, les fichiers, etc. C'est très puissant, mais la documentation — tout en anglais — est parfois un peu absconse (Clavier+ c'est juste génial à ce niveau).

Fonctionnalités communes

• Activation d'une fenêtre par son titre
• Restriction de l'usage d'un raccourci à une fenêtre donnée (via son titre)
• des configurations séparables par fichiers

Ce qu'apporte AHK

• les interfaces graphiques
• interaction avec le système de fichiers
• la superposition des configurations
• et beaucoup plus encore

En résumé

Pour celles et ceux qui souhaitent découvrir comment facilement paramétrer des raccourcis claviers, Clavier+ et fait pour vous. Pour aller (beaucoup beaucoup) plus loin AutoHotKey ouvre tout un univers de possibilités.

PS

Quelque raccourcis que j'utilise tout le temps

• rappel des commandes passées (PACbase et ISPF)
• lancement des règles sous Outlook
• recherche des erreurs de compilation COBOL sous VScode
• configuration et tri des SYSOUT sous SDSF

Tip

Ne pas rager pas si votre tout dernier raccourci ne fonctionne pas avec Clavier+ : vous avez certainement laissé la fenêtre de configuration ouverte…

Nous sommes fiers de vous annoncer la 13ᵉ édition de Kernel Recipes. Elle aura lieu du 21 au 23 septembre 2026 à Paris, à la Fondation Biermans-Lapôtre, 9A boulevard Jourdan dans le 14ᵉ, RER Cité universitaire. Comme les années précédentes, une vingtaine d’interventions autour du fonctionnement de la communauté, des outils, de Rust, de la sécurité… et, pour la première fois (mais de façon raisonnée), de l’IA appliquée au développement noyau.

Le parrain de cette édition : Jonathan Corbet

Cette année, nous avons l’immense honneur d’accueillir Jonathan Corbet en tant que parrain de l’édition. Rédacteur en chef de LWN.net et observateur privilégié du développement du noyau depuis des décennies, il a participé grandement à la construction du programme – autant dire que l’édition s’annonce très bien !

Les conférences : variées, avec un peu d’IA, du Rust, de la sécurité, des outils…

Le programme mêle, comme d’habitude, mainteneurs historiques et nouvelles têtes :

• Steven Rostedt revient sur les coulisses peu glorieuses des futex (Futex: The good, the bad and the ugly! (mostly ugly)) ;
• côté Rust, Miguel Ojeda fait le point sur Rust for Linux et Danilo Krummrich (Red Hat, fondateur du driver Nova pour GPU NVIDIA) détaille comment imposer à la compilation les règles de cycle de vie des drivers ;
• côté sécurité, Marta Rybczynska se demande si Linux est enfin secure by default, et Greg Kroah-Hartman abordera la sécurité à l’ère des LLM ;
• côté outils, on retrouve Patrick Steinhardt (GitLab) sur l’actualité de Git, Konstantin Ryabitsev sur l’infrastructure kernel.org, et Matthieu Baerts sur MPTCP ;
• côté ordonnancement et mémoire, SeongJae Park présente DAMOS, Changwoo Min et Gavin Guo (Igalia) parlent de leur ordonnanceur BPF LAVD, Victor Laforet (Inria) de verrouillage et ordonnancement, et Roman Guschchin de la gestion mémoire des cgroups ;
• et bien sûr, Martin Uecker, Arnd Bergmann, Detlev Casanova (Collabora) et d’autres viendront compléter ce menu copieux.

Et la fameuse touche IA, justement : oui, le sujet est au programme cette année, mais on est resté raisonnable :

• Greg Kroah-Hartman, « You are holding it wrong! » : comment obtenir d’un LLM un correctif de bug réellement valide, ce qui marche, ce qui ne marche pas, et pourquoi la plupart des gens s’y prennent mal ;
• Roman Guschchin, The Sashiko review system : un système de revue de patchs assisté par IA, conçu spécifiquement pour le noyau, qui aurait détecté plus de la moitié des bugs dans un corpus de 1000 correctifs historiques ayant pourtant passé la revue humaine.

Deux conférences, une seule vraie question : à quoi ressemble l’outillage assisté par IA quand il se confronte à la rigueur du développement noyau ?

Comme chaque année, Kernel Recipes organise ses enchères caritatives ! Cette année, nous avons souhaité mettre à nouveau en lumière le travail de la Software Freedom Conservancy. Bradley Kühn interviendra sur ce sujet le 22 septembre, juste avant le lancement des enchères.

Dans la salle

Frank sera bien sûr de la partie pour croquer sur le fait les orateurs et oratrices, mais aussi participants, perpétuant une tradition désormais incontournable de la conférence.

Notre mascotte est en train de se faire une beauté et devrait apparaître prochainement dans de nouveaux habits.

Sponsors

La conférence ne pourrait pas avoir lieu sans nos sponsors. Ils nous supportent en 2026 : Meta, ARM, PremDay, Jump Trading, HaProxy, Igalia, Collabora et d’autres à venir très bientôt.