❌

Vue lecture

Il y a de nouveaux articles disponibles, cliquez pour rafraĂźchir la page.

Deno 2.0 est lĂ 

Le temps oĂč Node.js rĂ©gnait en maĂźtre comme la solution incontournable pour exĂ©cuter du code JavaScript cĂŽtĂ© serveur est-il rĂ©volu ? En tout cas, il a aujourd’hui des challengers de taille comme Bun (qui pourrait lui aussi mĂ©riter une dĂ©pĂȘche) ou Deno. C'est donc de ce dernier qu'il sera question dans cette dĂ©pĂȘche, Ă  l'occasion de la sortie de sa version 2.0

Sommaire

Titre de l'image

Pour rappel

Deno est un runtime JavaScript et TypeScript. Il a vu le jour suite au constat de Ryan Dahl (crĂ©ateur aussi de Node.js), que Node avait des problĂšmes de conceptions, et qu'il Ă©tait nĂ©cessaire de repartir de zĂ©ro en tenant compte de l'expĂ©rience de Node pour ne pas refaire les mĂȘmes erreurs. Il imagine Deno comme un runtime avec un modĂšle de sĂ©curitĂ© par dĂ©faut plus strict. Les programmes Deno n'ont pas accĂšs au systĂšme de fichiers, au rĂ©seau ou Ă  l'environnement, sauf si on leur accorde explicitement ces permissions. Deno est Ă©crit en Rust, et se base sur le moteur JavaScript V8 de Google. Deno se distingue Ă©galement de Node en offrant la possibilitĂ© d'importer les dĂ©pendances via des URL, mettant en cache chaque module lors de l’importation pour amĂ©liorer la vitesse d’exĂ©cution.

La mascotte !

La premiĂšre chose notable quand on passe de Node.js Ă  Deno, c'est sa mascotte ! En effet, mĂȘme si Node.js possĂšde bien une petite tortue comme mascotte, celle-ci n'est utilisĂ©e nulle part ! Personnellement, j'ai toujours trouvĂ© bien plus chouettes les projets qui ont des petites bestioles comme mascotte (Mozilla, Tux 
). Et chez Deno, le dinosaure mascotte est omniprĂ©sent sur tout le site. Et en plus, Ă  l'occasion de la version 2.0, on peut habiller notre dino sur la home page du projet ! Et ça c'est cool ! Voici le mien, qui est en compagnie de Ferris, la mascotte officieuse de Rust !

Mon dino

Bon, comme je ne suis pas sĂ»r que tout le monde partage ma passion pour les mascottes, on va passer au cĂŽtĂ© plus technique ! đŸ€Ł

Deno 1.x, des dĂ©buts difficiles !

La version 1.0 sortie en mai 2020 a du mal Ă  se faire une place et reste dans l'ombre de son grand frĂšre. En effet, mĂȘme si Deno offre un grand lot de nouveautĂ©s et est plus sĂ©curisĂ© par dĂ©faut, la trĂšs large adoption de Node et le fait que les projets dĂ©veloppĂ©s pour Node ne sont pas forcĂ©ment compatibles avec Deno rend l’adoption de ce dernier difficile. De plus, l'utilisation de CDN plutĂŽt que d'installer les dĂ©pendances localement (dans le rĂ©pertoire node_modules) a certes de nombreux avantages, mais cela rend votre projet dĂ©pendant de disponibilitĂ© du rĂ©seau ou peut entraĂźner des problĂšmes de performances si le CDN est Ă©loignĂ© gĂ©ographiquement.

Les nouveautés de la version 2.0

Deno est désormais 100% compatible avec Node.js, et un gestionnaire de paquets officiel a vu le jour. Vous pouvez maintenant utiliser deno add et deno removepour ajouter ou retirer un paquet à votre projet.

Autour du projet Deno, JavaScript Registry (JSR) un dĂ©pĂŽt de paquets JavaScript universel !

Le registre NPM s'est construit autour de Node.js afin de gĂ©rer facilement les dĂ©pendances de nos projets. Il a donc Ă©tĂ© dĂ©veloppĂ© pour Node.js Ă  une Ă©poque oĂč Node Ă©tait la seule solution pour exĂ©cuter du code JavaScript cĂŽtĂ© serveur. En prĂšs de 15 ans, le registre NPM a rassemblĂ© un peu moins de 3 millions de paquets et a trĂšs largement rempli sa mission toutes ces annĂ©es. Mais aujourd'hui, la situation a changĂ©, il existe plusieurs runtimes pouvant exĂ©cuter du code JavaScript (ou TypeScript) cĂŽtĂ© serveur. Et du cĂŽtĂ© front-end, les frameworks se sont multipliĂ©s et sont devenus de plus en plus complexes et nĂ©cessitent aussi l'utilisation d'un gestionnaire de paquets. Un registre de paquets fondĂ© autour de Node.js uniquement est donc beaucoup moins pertinent qu'en 2010.
C'est donc pourquoi, Ă  l'initiative du projet Deno, un nouveau registre de paquets JavaScript et TypeScript universel pointe aujourd'hui le bout de son nez. Il s'agit donc de JSR (JavaScript Registry).

Dans JSR, quand on va sur la page d'un paquet, en haut Ă  droite, on a les logos des environnements compatibles avec le paquet :

Titre de l'image

Performances du runtime

Niveau performance, ça donne quoi ?

On voit souvent l'affirmation que Deno serait plus rapide que Node.js. Mais ça donne quoi en rĂ©alitĂ© ?

J'ai voulu faire un petit test sans prĂ©tentions pour voir ce que ça donne. Je voulais faire des tests plus poussĂ©s sur diffĂ©rents systĂšmes d'exploitation et architectures, mais par manque de temps, le test sera donc fait sur un seul systĂšme et un seul ordinateur et il s'agit d'un Mac
 Un comble pour LinuxFr.org, mais c'est l'ordinateur que j'avais Ă  disposition Ă  ce moment-lĂ . Mais sinon, je ne porte pas spĂ©cialement Apple dans mon cƓur, bien au contraire !

J'ai testĂ© l’exĂ©cution d'une mĂȘme API sur Node. et Deno pour voir les diffĂ©rences de performance entre ces solutions. Pour ce test, j'ai utilisĂ© une API Rest que j'ai dĂ©veloppĂ©e pour le site de la sociĂ©tĂ© AudioSoft. J'ai fait la mĂȘme requĂȘte POST 10 fois sur la mĂȘme route avec les mĂȘmes donnĂ©es. Il est important de prĂ©ciser que c'est la premiĂšre fois que je fais ce genre de tests, et que je ne fais peut-ĂȘtre pas tout dans les rĂšgles de l'art. Il y a des Ă©lĂ©ments extĂ©rieurs Ă  Node et Deno qui peuvent influencer les scores. Notamment, la base de donnĂ©es utilisĂ©e pour le test Ă©tait accessible via Internet, et des diffĂ©rences de dĂ©bit ont pu fausser les tests.

Test sur un MacBook Pro (2,6 GHz Intel Core i7 6 cƓurs, AMD Radeon Pro 5300M 4 Go Intel UHD Graphics 630 1536 Mo, 16 Go 2667 MHz DDR4) sous macOS Sonoma

Node: Le temps moyen pour exécuter le test de 126 millisecondes
Deno: Le temps moyen pour exécuter le test de 93 millisecondes

Performances du gestionnaire de paquets

Comme dit précédemment, Deno c'est aussi un gestionnaire de paquets. J'ai donc trouvé intéressant de tester les principaux gestionnaires de paquets sur différents environnements.
Pour ce test je me base sur la mĂȘme API Rest que pour le test prĂ©cĂ©dant, les dĂ©pendances Ă  installer pour cette API sont : bcrypt, body-parser, dotenv, express, jsonwebtoken, mariadb, multer, mysql2, nodemailer, et sequelize. Le test a Ă©tĂ© fait sur un MacBook Pro. Pour effectuer ce test, le cache des gestionnaires de paquets ont Ă©tĂ© nettoyĂ©s et les fichiers-verrous supprimĂ©s.

Avec NPM, l'installation a mis 10 secondes.

Avec Deno, l'installation a mis 1 seconde.

Avec Bun, l'installation a mis 3 secondes.

On voit trĂšs clairement que NPM est beaucoup plus lent que ses deux concurrents. L'Ă©cart est plus faible entre Deno et Bun. Mais Deno est bien le plus rapide des trois.

Avant de rĂ©aliser ce test, j'en ai effectuĂ© un en oubliant de nettoyer le cache et de supprimer package-lock.json. Les rĂ©sultats Ă©taient alors 8 secondes pour NPM, 5 secondes pour Deno et 4 secondes pour Bun. Il est logique de constater que NPM est plus rapide, en revanche, je trouve surprenant que Deno et Bun aient Ă©tĂ© ralentis. Il est possible que les gestionnaires de paquets aient parcouru package-lock.json pour garder les versions prĂ©sentes dans ce fichier, ce qui les aurait tous les trois ralentis. Et NPM a peut-ĂȘtre pu bĂ©nĂ©ficier de son cache (car je l'utilise bien plus que les deux autres sur mon ordinateur), Deno et Bun eux n'avaient peut-ĂȘtre pas grand-chose dans leurs caches, ont donc Ă©tĂ© ralentis. Il est donc important de supprimer les lockfile en cas de migration d'un projet.

Comme je le disais plus haut, c'est la premiĂšre fois que j'effectue ce genre de test comparatif. Si vous avez des conseils sur les bonnes mĂ©thodes pour faire des tests plus fiables, ça m’intĂ©resse !

Deno 2.1 est lĂ 

Étant donnĂ© que j'ai mis environ un siĂšcle pour rĂ©diger cette dĂ©pĂȘche, Deno 2.1 est sortie entre temps ! đŸ€Ł
Je vous liste donc les principales nouveautĂ©s apportĂ©es Ă  la version 2.1 sans les commenter 😉

  • Support natif de WebAssembly (Wasm) : Il est dĂ©sormais possible d'importer directement des modules Wasm, simplifiant leur utilisation et amĂ©liorant les performances.
  • Version Long Term Support (LTS) : Deno 2.1 inaugure la premiĂšre version LTS, garantissant des correctifs de bugs et des amĂ©liorations de performance pendant
 Six mois
 On n'est pas encore aux 30 mois des versions LTS de Node.js
 Cela viendra peut-ĂȘtre plus tard. 🙂
  • Commande deno init --npm vite : Cette commande simplifie la crĂ©ation de nouveaux projets en utilisant des outils comme Vite, en automatisant l'initialisation et en rĂ©duisant la configuration manuelle.
  • Gestion des dĂ©pendances : Introduction de la commande deno outdated pour gĂ©rer les mises Ă  jour des dĂ©pendances JSR et npm.

Conclusion

Si vous ĂȘtes dĂ©veloppeur Node.js, je vous conseille de vous intĂ©resser Ă  Deno, et mĂȘme Ă  Bun. Je ne sais pas si ces deux runtime sont totalement prĂȘts pour des projets en production (par exemple, Deno 2.1 n'a que 6 mois de durĂ©e de vie, ce qui est plutĂŽt contraignant pour les serveurs.). Mais peut-ĂȘtre que dans un futur proche, il sera cohĂ©rent de migrer vers l'un de ces deux-lĂ .

Commentaires : voir le flux Atom ouvrir dans le navigateur

GIMP 3.0 RC1 est sorti

Note : cette dĂ©pĂȘche est une traduction de l'annonce officielle de la sortie de GIMP 3.0 RC1 du 6 novembre 2024 (en anglais).

Nous sommes trĂšs heureux de partager la premiĂšre version candidate de la trĂšs attendue GIMP 3.0 ! Nous avons travaillĂ© dur depuis notre derniĂšre mise Ă  jour de dĂ©veloppement pour la prĂ©parer, et nous avons hĂąte que tout le monde puisse enfin voir le rĂ©sultat.

GIMP 3.0 RC1: écran de démarrage

Nouvel écran de démarrage de la version candidate, par Sevenix (CC by-sa 4.0) - GIMP 3.0 RC1

Alors, qu’est-ce qu’une « version candidate Â» (release candidate, RC, en anglais) exactement ? Une version candidate est quelque chose qui pourrait ĂȘtre prĂȘt Ă  ĂȘtre GIMP 3.0, mais nous voulons que la communautĂ© la plus large la teste en premier et rapporte les problĂšmes qu’elle trouve. Si les retours des utilisateurs ne rĂ©vĂšlent que des bugs mineurs et faciles Ă  corriger, nous rĂ©soudrons ces problĂšmes et publierons le rĂ©sultat sous la forme de GIMP 3.0. Cependant, nous espĂ©rons et nous nous attendons Ă  ce qu’un public beaucoup plus large essaie la 3.0 RC1 — y compris de nombreuses personnes qui n’ont utilisĂ© que la 2.10 jusqu’à prĂ©sent. Si des bugs et des rĂ©gressions importants sont dĂ©couverts et nĂ©cessitent des modifications de code substantielles, nous devrons peut-ĂȘtre publier une deuxiĂšme version candidate pour des tests plus approfondis.

Sommaire

Nouveaux graphismes

IcĂŽnes de Wilber

Le logo actuel de Wilber a Ă©tĂ© crĂ©Ă© par Jakub Steiner pour GIMP 2.6 en 2008 ! Bien qu’il s’agisse toujours d’un logo fantastique, les tendances en matiĂšre de design ont quelque peu changĂ© au cours des seize derniĂšres annĂ©es et l’apparence plus dĂ©taillĂ©e de Wilber dĂ©tonne sur les ordinateurs de bureau modernes.

C’est pourquoi, en collaboration avec d’autres contributeurs, Aryeom a dĂ©veloppĂ© notre nouveau logo pour GIMP 3.0 !

New Wilber Icon

Nouvelle icĂŽne de Wilber, par Aryeom (CC by-sa 4.0)

Si vous souhaitez en savoir plus sur les choix de conception, d’utilisation et les variantes de conception, veuillez consulter notre guide du logo. Nous avons Ă©galement documentĂ© l’histoire du logo Wilber.

Écran de dĂ©marrage (Splash Screen)

Notre magnifique nouvel Ă©cran d’accueil (prĂ©sentĂ© en haut de cet article) a Ă©tĂ© crĂ©Ă© par le contributeur et artiste de longue date Sevenix ! Vous pouvez voir plus de ses rĂ©alisations sur sa page d’art personnelle.

À l’avenir, nous prĂ©voyons de changer plus souvent l’image de dĂ©marrage pour mettre en valeur toutes sortes d’Ɠuvres crĂ©Ă©es avec GIMP (photographie, illustration, design
).
À ce sujet, nous avons aussi crĂ©Ă© une page d’archive des Ă©crans de dĂ©marrage pour garder en mĂ©moire les Ɠuvres prĂ©sentes et passĂ©es contribuĂ©es par des artistes au projet.

AmĂ©liorations du thĂšme d’icĂŽnes Legacy

L’une des principales amĂ©liorations apportĂ©es par le portage GTK3 est que les icĂŽnes vectorielles de l’interface utilisateur s’adaptent dĂ©sormais plus proprement Ă  vos prĂ©fĂ©rences. Cependant, notre thĂšme d’icĂŽnes Legacy Ă©tait principalement constituĂ© d’images raster (PNG), il ne pouvait donc pas tirer parti du systĂšme de mise Ă  l’échelle de GTK3. Le contributeur Denis Rangelov a relevĂ© le dĂ©fi de taille de recrĂ©er les icĂŽnes d’outils Legacy en SVG. DĂ©sormais, les deux thĂšmes d’icĂŽnes de GIMP sont superbes sur les Ă©crans HiDPI !

Vectorized Legacy Icon theme

IcĂŽnes d’outils du thĂšme Legacy Icon Ă  l’échelle par Denis Rangelov (CC by-sa 4.0)

Le travail n’est pas terminĂ©, car de nombreuses icĂŽnes ne sont toujours pas adaptatives et certaines icĂŽnes sont toujours manquantes. Denis a exprimĂ© son intĂ©rĂȘt Ă  continuer d’amĂ©liorer le thĂšme d’icĂŽnes Legacy, nous espĂ©rons donc le renommer Classic lorsque ce projet sera terminĂ©, pour montrer qu’il est dĂ©sormais bien maintenu.

Invasion de l’espace colorimĂ©trique

L’un des changements clĂ©s de la version 2.99.18 a Ă©tĂ© l’amĂ©lioration massive de la gestion des couleurs dans GIMP. Comme ce travail n’était pas entiĂšrement terminĂ© dans la version 2.99.18, il a constituĂ© un obstacle majeur Ă  la sortie de la version 3.0 RC1.

Depuis cette version, nous avons trouvĂ© et corrigĂ© un certain nombre de bugs et de zones manquantes qui devaient ĂȘtre compatibles avec l’espace colorimĂ©trique. Nous avons Ă©galement examinĂ© les rapports de l’experte en couleurs Elle Stone pour nous assurer que les valeurs de couleur affichĂ©es par GIMP sont aussi prĂ©cises que possible. En mĂȘme temps, il est trĂšs important de garantir que les fichiers de projet XCF crĂ©Ă©s dans GIMP 2.10 et avant s’afficheront de la mĂȘme maniĂšre lorsqu’ils sont ouverts dans 3.0. Par exemple, l’un des premiers logos Google a Ă©tĂ© crĂ©Ă© dans GIMP — et si vous ouvrez le fichier de projet XCF d’origine dans GIMP 3.0 RC1, il apparaĂźt toujours de la mĂȘme maniĂšre qu’à sa crĂ©ation en 1998 !
Par consĂ©quent, nous avons examinĂ© en profondeur les diffĂ©rents modes de calque pour garantir que l’engagement en matiĂšre de compatibilitĂ© soit conservĂ© pour cette version.

L’invasion de l’espace colorimĂ©trique est un projet de longue haleine, qui se poursuivra aprĂšs la sortie de GIMP 3.0.

Finalisation de l’API publique

Une autre tĂąche qui devait ĂȘtre terminĂ©e avant la sortie de la version 3.0 est de finaliser l’API publique. Depuis notre dernier article, nous avons terminĂ© les changements majeurs restants — le remplacement de toutes les instances de nos structures de couleurs personnalisĂ©es GimpRGB par la GeglColor mieux gĂ©rĂ©e en termes de couleurs et l’amĂ©lioration de nos formats de tableau afin que le nombre d’élĂ©ments n’ait pas Ă  ĂȘtre spĂ©cifiĂ© sĂ©parĂ©ment. Ce travail a Ă©tĂ© un long processus de la part de Jehan et Lloyd Konneker, avec beaucoup de tests de bon fonctionnement et de retours de la part d'Anders Jonsson.

En outre, un certain nombre de fonctions ont Ă©tĂ© ajoutĂ©es, renommĂ©es ou supprimĂ©es de l’API publique par rapport Ă  la version 2.10. Par exemple, un ancien patch de Massimo Valentini ajoute gimp-context-get-emulate-brush-dynamics et gimp-context-set-emulate-brush-dynamics, qui permettent aux dĂ©veloppeurs de scripts et de greffons d’utiliser le paramĂštre Émuler la dynamique du pinceau lors de la peinture. D’autre part, les diffĂ©rentes fonctions gauss ont toutes Ă©tĂ© regroupĂ©es en une seule fonction, plug-in-gauss. Bien que ce changement nĂ©cessite quelques mises Ă  jour dans les scripts existants, les dĂ©veloppeurs ont dĂ©sormais un contrĂŽle plus direct sur l’effet de flou gaussien plutĂŽt que de s’appuyer sur des valeurs prĂ©dĂ©finies cachĂ©es.

L’API Ă©tant dĂ©sormais stable, les dĂ©veloppeurs de greffons et de scripts peuvent commencer Ă  porter leurs scripts 2.10 basĂ©s sur cette version. Vous pouvez trouver la documentation initiale de l’API sur notre site de dĂ©veloppement. Nous avons l’intention d’ajouter davantage de tutoriels et de guides de portage sur le site pendant la phase de publication. Nous vous encourageons Ă©galement Ă  consulter les greffons Script-fu et Python dans notre rĂ©fĂ©rentiel pour voir des exemples fonctionnels de la nouvelle API.

Mises Ă  jour de l’édition non destructive

Depuis notre derniÚre mise à jour, nous avons continué à apporter des améliorations et des corrections de bugs à notre code de filtre non destructif. Bon nombre de ces problÚmes ont été signalés par Sam Lester lors du développement et des tests de ses filtres GEGL tiers.

Bien que les filtres non destructifs aient Ă©tĂ© un ajout trĂšs populaire Ă  GIMP 3.0, certains des premiers utilisateurs ont demandĂ© que nous fournissions un moyen de revenir au flux de travail destructif d’origine. Par consĂ©quent, nous avons ajoutĂ© une case Ă  cocher facultative « Fusionner les filtres Â» au bas des filtres NDE. Si cette case est cochĂ©e, le filtre sera immĂ©diatement fusionnĂ© aprĂšs sa validation. Notez que les filtres ne peuvent pas ĂȘtre appliquĂ©s de maniĂšre destructive sur des groupes de calques â€” dans ces cas, l’option de fusion des filtres n’est pas disponible.

Example of Merge Filter checkbox

Exemple de filtre avec la case Ă  cocher « Merge Filter Â» (Fusionner les filtres) - GIMP 3.0 RC1

Dans le mĂȘme ordre d’idĂ©es, Jehan a Ă©galement implĂ©mentĂ© le stockage de la version des filtres dans les fichiers de projet XCF de GIMP. Cela nous permettra de mettre Ă  jour les filtres Ă  l’avenir sans affecter l’apparence des anciens fichiers de projet lorsqu’ils sont ouverts. Des travaux supplĂ©mentaires seront nĂ©cessaires dans GEGL pour implĂ©menter complĂštement cette fonctionnalitĂ©, mais cela peut ĂȘtre fait aprĂšs la version 3.0 sans affecter les fichiers de projets existants.

Interface utilisateur

GIMP 3.0 RC1 contient plusieurs mises Ă  jour de l’interface utilisateur. Par exemple, davantage d’aspects du GUI peuvent dĂ©sormais tirer parti des fonctionnalitĂ©s de sĂ©lection multiple implĂ©mentĂ©es par Jehan dans les versions antĂ©rieures de 2.99.

Nous avons Ă©galement restaurĂ© la possibilitĂ© d’utiliser la molette de dĂ©filement de la souris pour parcourir les diffĂ©rents onglets de dialogue ancrables. Cette fonctionnalitĂ© existait dans GTK2 mais supprimĂ©e dans GTK3. À la demande d’un utilisateur, nous avons rĂ©implĂ©mentĂ© cette fonctionnalitĂ© dans GIMP lui-mĂȘme sur la base d’une implĂ©mentation similaire dans geany.

Au cours du dĂ©veloppement, nous avons reçu un rapport indiquant que le dĂ©filement des crĂ©dits dans notre boĂźte de dialogue À Propos pouvait provoquer une gĂȘne en raison de son mouvement. Par consĂ©quent, nous avons ajoutĂ© un code pour vĂ©rifier le paramĂštre « Animation rĂ©duite Â» de votre systĂšme d’exploitation et dĂ©sactiver ces animations dans GIMP selon vos paramĂštres de prĂ©fĂ©rence.

Greffons

Comme nous sommes en pĂ©riode de gel des fonctionnalitĂ©s depuis la derniĂšre version 2.99, la plupart des modifications apportĂ©es aux greffons ont Ă©tĂ© des mises Ă  jour d’API et des corrections de bugs (certaines d’entre elles pour des problĂšmes qui Ă©taient assez anciens). Cependant, quelques amĂ©liorations plus petites ont Ă©tĂ© implĂ©mentĂ©es.

BMP

Le format BMP prend dĂ©sormais en charge les images 64 bits par pixel. Le nouveau contributeur Rupert Weber nous a aidĂ© Ă  ajouter la prise en charge de l’importation correcte de ce format BMP. Il a Ă©galement soumis des correctifs avec plus de corrections pour notre greffon BMP et notre pipeline de test.

TIFF

Depuis GIMP 2.99.16, nous pouvons importer des fichiers TIFF avec des calques au format Photoshop. Cependant, le programme Alias/Autodesk Sketchbook a crĂ©Ă© sa propre norme pour enregistrer les calques, ce qui n’était pas compatible. Comme cela a Ă©tĂ© signalĂ© comme un bug dans notre outil de suivi des problĂšmes, nous avons Ă©galement ajoutĂ© la prise en charge du chargement de calques Ă  partir de fichiers TIFF enregistrĂ©s au format Sketchbook.

GEGL et babl

GEGL et babl ont tous deux connu un certain nombre de mises à jour depuis leurs derniÚres versions en février.

GEGL 0.4.50 introduit plusieurs nouveaux filtres créés par Sam Lester.

  • Lueur intĂ©rieure (Inner Glow)

  • Biseau (Bevel)

  • Styles GEGL (GEGL Styles)

"GEGL Styles" effect in GIMP 3.0 RC1

Vous pouvez y accĂ©der via l’outil OpĂ©rations GEGL ou en les recherchant avec le raccourci d’action de recherche /.

Øyvind KolĂ„s a apportĂ© un certain nombre de corrections de bugs et d’amĂ©liorations Ă  la stabilitĂ© de GEGL. Plusieurs modifications ont Ă©galement Ă©tĂ© apportĂ©es en rapport avec l’invasion de l’espace colorimĂ©trique dans GIMP, comme l’ajout de mĂ©thodes pratiques pour obtenir et dĂ©finir les GeglColor dans les modĂšles de couleurs HSV(A) et HSL(A), implĂ©mentĂ©es par Alx Sa. Jacob Boerema et son Ă©tudiant du Google Summer of Code (GSoC) Varun Samaga B L ont fusionnĂ© un certain nombre d’amĂ©liorations Ă  la version OpenCL des filtres. Bien que GIMP n’active toujours pas OpenCL par dĂ©faut, leur travail nous rapproche beaucoup de la possibilitĂ© de le faire. Nous discuterons de ces amĂ©liorations dans un prochain article.

babl 0.1.110 a Ă©galement reçu quelques contributions au cours de ce cycle. Jehan a implĂ©mentĂ© de nouveaux processus de conversion entre les modĂšles de couleurs RVB et HSL, ce qui amĂ©liore les performances d’un certain nombre de filtres par rapport Ă  GIMP 2.99.18. Il a Ă©galement corrigĂ© certaines parties du code qui se comportaient diffĂ©remment selon que votre processeur prenait en charge SSE2 ou non. Øyvind KolĂ„s a amĂ©liorĂ© la prĂ©cision de plusieurs sections de code lors de la conversion de valeurs Ă  virgule flottante en valeurs entiĂšres. De plus, Lukas Oberhuber a trouvĂ© et corrigĂ© une fuite de mĂ©moire et Jacob Boerema a corrigĂ© un problĂšme oĂč les images avec Not a Number/NaN pouvaient provoquer un plantage.

Statistiques de sortie

Depuis GIMP 2.99.18, dans le dĂ©pĂŽt principal de GIMP :

  • 384 rapports ont Ă©tĂ© fermĂ©s comme CORRIGÉS.
  • 442 demandes de fusion ont Ă©tĂ© acceptĂ©es.
  • 1892 commits ont Ă©tĂ© poussĂ©s.
  • 31 traductions ont Ă©tĂ© mises Ă  jour : basque, biĂ©lorusse, brĂ©silien portugais, anglais britannique, bulgare, catalan, chinois (Chine), chinois (TaĂŻwan), danois, nĂ©erlandais, galicien, gĂ©orgien, allemand, grec, hongrois, islandais, italien, corĂ©en, letton, norvĂ©gien nynorsk, polonais, portugais, russe, serbe, serbe (latin), slovĂšne, espagnol, suĂ©dois, turc, ukrainien, vietnamien.

72 personnes ont contribuĂ© Ă  des modifications ou des correctifs au code de base de GIMP 3.0.0 RC1 (l’ordre
est dĂ©terminĂ© par le nombre de commits ; certaines personnes sont dans plusieurs groupes) :

  • 27 dĂ©veloppeurs pour coder le code principal : Jehan, Alx Sa, Jacob Boerema, bootchk, Anders Jonsson, Øyvind KolĂ„s, Cheesequake, cheesequake, Niels De Graef, Idriss Fekir, Simon Budig, lillolollo, lloyd konneker, Andre Klapper, Andrzej Hunt, Bruno, Joachim Priesner, Nils Philippsen, Alfred Wingate, Bruno Lopes, Elle Stone, Kamil Burda, Luca Bacci, Mark Sweeney, Massimo Valentini, Oleg Kapitonov, Stanislav Grinkov, megakite.
  • 15 dĂ©veloppeurs de greffons ou modules : Alx Sa, Jehan, Lloyd Konneker, bootchk, Jacob Boerema, Anders Jonsson, Nils Philippsen, Andrzej Hunt, Andre Klapper, Rupert, Bruno Lopes, Daniel NovomeskĂœ, Mark Sweeney, Stanislav Grinkov, lillolollo .
  • 42 traducteurs : Martin, Yuri Chornoivan, Luming Zh, Rodrigo LledĂł, KolbjĂžrn StuestĂžl, Ekaterine Papava, Cheng-Chia Tseng, Sabri Ünal, Marco Ciampa, Tim Sabsch, Jordi Mas, Alexander Shopov, Anders Jonsson, Alan Mortensen, Asier Sarasua Garmendia, Sveinn Ă­ Felli, Andi Chandler, BalĂĄzs Úr, dimspingos, Juliano de Souza Camargo, Ngọc QuĂąn Tráș§n, Vasil Pupkin, Alexandre Prokoudine, Bruce Cowan, JĂŒrgen Benvenuti, Nathan Follens, ĐœĐžĐ»ĐŸŃˆ ĐŸĐŸĐżĐŸĐČоћ, BalĂĄzs MeskĂł, Christian Kirbach, Daniel, Emin Tufan Cetin, Fran Dieguez, Guntupalli Karunakar, Hugo Carvalho, Jehan, Philipp Kiemle, Piotr Drąg, Robin Mehdee, RĆ«dolfs Mazurs, Seong-ho Cho, VĂ­ttor Paulo Vieira da Costa, Ayesha Akhtar.
  • 7 crĂ©ateurs de ressources (icĂŽnes, thĂšmes, curseurs, Ă©cran de dĂ©marrage, mĂ©tadonnĂ©es
 mĂȘme si une bonne partie d’entre eux ont Ă©tĂ© dĂ©placĂ©s vers le rĂ©fĂ©rentiel gimp-data) : Alx Sa, Jehan, Bruno Lopes, Anders Jonsson, Jacob Boerema, bootchk, nb1 .
  • 10 contributeurs Ă  la documentation : Jehan, Bruno, Lloyd Konneker, Alx Sa, Bruno Lopes, Anders Jonsson, bootchk, Lukas Oberhuber, Andre Klapper, Jacob Boerema.
  • 11 contributeurs pour la compilation, l’empaquetage ou l’intĂ©gration continue : Bruno Lopes, Jehan, bootchk, Alx Sa, Lloyd Konneker, Jacob Boerema, Niels De Graef, Alfred Wingate, Lukas Oberhuber, Michael Schumacher, Anders Jonsson.

Contributions sur d’autres dĂ©pĂŽts dans GIMPverse  :

  • babl 0.1.110 est composĂ© de 22 commits par 7 contributeurs : Øyvind KolĂ„s, Jehan, Bruno Lopes, Anders Jonsson, Biswapriyo Nath, Jacob Boerema, Lukas Oberhuber.
  • GEGL 0.4.50 est composĂ© de 204 commits par 33 contributeurs : Øyvind KolĂ„s, Sam Lester, Martin, Varun Samaga B L, Yuri Chornoivan, Luming Zh, Rodrigo LledĂł, Jehan, Jordi Mas, Anders Jonsson, KolbjĂžrn StuestĂžl, Marco Ciampa, Sabri Ünal, Bruno Lopes, Alan Mortensen, Asier Sarasua Garmendia, Ekaterine Papava, Bruce Cowan, Lukas Oberhuber, Tim Sabsch, psykose, Alexandre Prokoudine, Alx Sa, Andi Chandler, Andre Klapper, ArtSin, Daniel Șerbănescu, Jacob Boerema, Joe Locash, Morgane Glidic, Niels De Graef, dimspingos, lillolollo.
  • ctx a enregistrĂ© 616 commits depuis la sortie de la version 2.99.18 par 2 contributeurs : Øyvind KolĂ„s, Ian Geiser.
  • gimp-data (nouveau rĂ©fĂ©rentiel contenant des images, des splashes, des icĂŽnes et d’autres donnĂ©es binaires pour le logiciel) ont eu 76 commits par 7 contributeurs : Jehan, Aryeom, Bruno, Alx Sa, Denis Rangelov, Anders Jonsson, Bruno Lopes.
  • La version gimp-macos-build (scripts d’empaquetage pour macOS) a eu 41 commits par 3 contributeurs : Lukas Oberhuber, Bruno Lopes, Jehan.
  • La version flatpak a comptĂ© 38 commits de 4 contributeurs : Bruno Lopes, Jehan, Hubert FiguiĂšre, Will Thompson.
  • Notre site Web principal a enregistrĂ© 60 commits depuis la sortie de la version 2.10.38 par 5 contributeurs : Jehan, Alx Sa, Andre Klapper, Bruno Lopes et Denis Rangelov.
  • Notre site Web de dĂ©veloppeur a enregistrĂ© 33 commits depuis la sortie de la version 2.10.38 par 5 contributeurs : Bruno Lopes, Jehan, Lloyd Konneker, Alx Sa, Lukas Oberhuber.
  • Notre documentation 3.0 a enregistrĂ© 928 commits depuis la version 2.99.18 par 14 contributeurs : Andre Klapper, KolbjĂžrn StuestĂžl, Jacob Boerema, Alan Mortensen, Yuri Chornoivan, Jordi Mas, Marco Ciampa, Anders Jonsson, Sabri Ünal, dimspingos, Alx Sa, Andi Chandler, Daniel, Nathan Follens.

N’oublions pas de remercier toutes les personnes qui nous aident Ă  trier dans Gitlab, Ă  signaler les bugs et Ă  discuter des amĂ©liorations possibles avec nous.
Notre communautĂ© est Ă©galement profondĂ©ment reconnaissante envers les guerriers d’Internet qui gĂšrent nos divers canaux de discussion ou comptes de rĂ©seaux sociaux tels que Ville PĂ€tsi, Liam Quin, Michael Schumacher et Sevenix !

Note : compte tenu du nombre de parties dans GIMP et de la façon dont nous obtenons des statistiques via le script git, des erreurs peuvent se glisser dans ces statistiques. N’hĂ©sitez pas Ă  nous dire si nous avons oubliĂ© ou mal classĂ© des contributeurs ou des contributions.

Modifications futures du processus de publication

Nous sommes bien conscients que le chemin vers GIMP 3.0 a Ă©tĂ© long et que les utilisateurs de GIMP 2.10 n’ont pas eu accĂšs Ă  toutes les nouvelles fonctionnalitĂ©s sur lesquelles nous avons travaillĂ© au fil des ans. À l’avenir, nous restructurerons notre processus de dĂ©veloppement pour rĂ©duire le temps entre les versions. Comme mentionnĂ© briĂšvement dans notre feuille de route 3.0, nous voulons nous concentrer sur des versions plus petites et axĂ©es sur les fonctionnalitĂ©s. Cela signifie que nous visons la sortie de GIMP 3.2 dans l’annĂ©e qui suit la sortie finale de 3.0, plutĂŽt qu’en 2050 comme on le dit souvent en plaisantant ! Des micro-versions avec des corrections de bugs peuvent survenir entre-temps.

Des versions plus petites avec quelques « grosses Â» fonctionnalitĂ©s nous permettront Ă©galement de tester plus en profondeur chaque changement, amĂ©liorant encore la stabilitĂ© de chaque version. Au cours du processus de dĂ©veloppement de la version 3.0, des dĂ©veloppeurs comme Jacob Boerema, Lloyd Konneker, Bruno Lopes et Jehan ont crĂ©Ă© et amĂ©liorĂ© nos processus de tests automatisĂ©s pour dĂ©tecter et identifier les bugs plus tĂŽt. Nous parlerons plus en dĂ©tail de ces amĂ©liorations dans de futurs articles.

Autour de GIMP

Miroirs de téléchargement

Depuis notre derniÚre actualité, 8 nouveaux miroirs ont été proposés à GIMP par :

  • Sahil Dhiman, Inde
  • FCIX, en RĂ©publique Dominicaine, en Australie et 2 aux USA.
  • Taiwan Digital Streaming Co., TaĂŻwan
  • OSSPlanet, TaĂŻwan
  • Shrirang Kahale, Inde

Cela nous amĂšne Ă  un total de 56 miroirs du monde entier !

World Map of GIMP Mirror locations

Carte des miroirs GIMP dans le monde, générée à partir de MirrorBits

Les miroirs sont importants, car ils aident le projet en répartissant la charge des dizaines de milliers de téléchargements quotidiens. De plus, en ayant des miroirs répartis dans le monde entier, nous faisons en sorte que tout le monde puisse avoir un accÚs rapide au téléchargement de GIMP.

Modifications de l’infrastructure

Bruno Lopes a vĂ©ritablement pris des initiatives pour amĂ©liorer notre processus de construction et d’empaquetage sur plusieurs plateformes.

Au cours de l’étĂ©, il a crĂ©Ă© une version expĂ©rimentale d’AppImage (comme dĂ©taillĂ© dans un article d’actualitĂ© prĂ©cĂ©dent). Si vous souhaitez l’amĂ©liorer davantage et, espĂ©rons-le, le rendre disponible en tĂ©lĂ©chargement standard, veuillez nous contacter ! Bruno a Ă©galement crĂ©Ă© des scripts de construction flatpak pour rendre le processus de crĂ©ation de votre propre flatpak GIMP beaucoup plus facile.

Beaucoup de travail a Ă©tĂ© fait pour amĂ©liorer notre prĂ©sence sur le Microsoft Store pour la version 3.0. Notre application GIMP 2.10 n’était pas entiĂšrement intĂ©grĂ©e Ă  la plateforme du store en raison de certaines limitations — il s’agit en rĂ©alitĂ© simplement d’un wrapper pour notre installateur GIMP existant. Par consĂ©quent, elle ne se mettait pas automatiquement Ă  jour pour les utilisateurs et il n’était pas possible d’automatiser les installations avec des outils comme Microsoft Intune. GrĂące aux nombreux efforts de Bruno, nous aurons une nouvelle application GIMP dans le Microsoft Store qui rĂ©sout ces problĂšmes (et bien d’autres) pour la version finale de GIMP 3.0. À partir de maintenant, nous disposons Ă©galement d’une version sĂ©parĂ©e de GIMP (Preview) qui vous permet d’installer des versions de dĂ©veloppement de maniĂšre similaire au flatpak BĂȘta sur Linux. Vous pouvez l’essayer sur ce lien vers le Microsoft Store pour GIMP (Preview).

(Pour des raisons techniques et de maintenance dĂ©crites ici, les binaires 32 bits ne seront pas disponibles dans les nouveaux paquets MSIX de GIMP, ce qui supprime malheureusement la prise en charge du greffon TWAIN hĂ©ritĂ© dans les paquets x64 et arm64 utilisĂ©s pour la numĂ©risation rapide. Si vous dĂ©pendez de ceux-ci, le programme d’installation .exe prend toujours en charge les processeurs 32 bits. Cependant, la prise en charge de cette architecture devrait ĂȘtre abandonnĂ©e Ă  l’avenir)

En outre, l’installateur Windows standard a Ă©tĂ© mis Ă  jour pour une conception plus moderne. Il vous permet Ă©galement d’installer des paquets de langue individuels et de dĂ©marrer GIMP immĂ©diatement aprĂšs la fin de l’installation. Pour les plus fĂ©rus de technologie, les scripts de build Windows ont Ă©galement Ă©tĂ© portĂ©s pour utiliser PowerShell, et les scripts de build croisĂ©s peuvent dĂ©sormais s’exĂ©cuter localement.

En raison des changements et des mises Ă  jour de notre infrastructure de crĂ©ation de logiciels, nous avons dĂ» augmenter la configuration minimale requise pour le systĂšme d’exploitation MacOS Ă  Big Sur (MacOS 11).

Accord d’hĂ©bergement fiscal de la Fondation GNOME

Plus tÎt cette année, la Fondation GNOME a annoncé un accord de parrainage fiscal avec GIMP. Tout cela est dû au travail acharné de Jehan pendant de nombreux mois. Nos objectifs avec cet accord sont de pouvoir proposer un financement stable pour les développeurs intéressés par un travail à long terme sur GIMP par le biais de bourses, et de fournir des moyens plus faciles pour les gens de contribuer au développement de GIMP. Ce travail est toujours en cours, nous ferons donc une annonce plus détaillée une fois que tout sera stabilisé.

Traductions

GrĂące Ă  des traducteurs bĂ©nĂ©voles, nous disposons dĂ©sormais d’une traduction de GIMP en bengali ! Si vous souhaitez traduire GIMP dans votre propre langue ou participer Ă  une traduction existante, vous pouvez dĂ©couvrir comment ici.

Télécharger GIMP 3.0 RC1

Vous trouverez toutes nos versions officielles sur le site officiel de GIMP (gimp.org) :

  • Paquets Linux flatpaks pour x86 et ARM (64 bits) avec des nightly-builds permettant de suivre l’avancement des dĂ©veloppements
  • Installateur Windows universel pour x86 (32 et 64 bits) et pour ARM (64 bits)
  • Paquet MSIX (aperçu GIMP) pour x86 (64 bits uniquement) et ARM (64 bits)
  • Paquets macOS DMG pour le matĂ©riel Intel
  • Paquets macOS DMG pour le matĂ©riel Apple Silicon

D’autres paquets rĂ©alisĂ©s par des tiers sont Ă©videmment attendus (paquets de distributions Linux ou *BSD, etc.).

Et ensuite ?

Nous entrons maintenant dans la derniĂšre Ă©tape de cette version majeure : les candidats Ă  la version finale ! Bien qu’il soit toujours possible d’espĂ©rer obtenir une Release Candidate correcte du premier coup, l’expĂ©rience nous dit que cette RC1 — qui est le rĂ©sultat de plus de 6 ans de travail — comportera possiblement des problĂšmes, des bugs, probablement des plantages dĂ©sagrĂ©ables. C’est lĂ  que nous avons besoin de vous tous ! Nous comptons sur tout le monde pour trouver et signaler les problĂšmes afin que la version 3.0.0 puisse vraiment ĂȘtre considĂ©rĂ©e comme stable. đŸ€—

Certains petits bugs peuvent ĂȘtre considĂ©rĂ©s comme secondaires (bien que nous acceptions toujours les rapports pour tous les bugs, mĂȘme les plus petits !), car la perfection n’existe pas vraiment dans les logiciels. Il y a d’autres choses en particulier que nous voulons vraiment dĂ©tecter, comme :

  • toute incohĂ©rence ou problĂšme dans l’API (elle restera stable pour toute la sĂ©rie v3, donc s’il y a des problĂšmes Ă  trouver, c’est maintenant ; nous voulons un framework de greffon robuste) ;
  • bugs lors de la lecture ou du rendu de fichiers XCF existants crĂ©Ă©s par d’anciennes versions stables de GIMP ;
  • plantages ;
  • rĂ©gressions ;
  • migration correcte de la configuration Ă  partir des versions stables prĂ©cĂ©dentes.

Nous ne donnons pas d’estimation de date pour la sortie de la version 3.0.0, tout d’abord parce que nous ne pouvons pas le savoir avec certitude, ensuite parce qu’à chaque fois que nous le faisons, les mĂ©dias semblent simplement survoler chaque avertissement de notre texte et transformer nos mots en promesses indĂ©fectibles. Sachez simplement que nous voulons Ă©galement que cela se produise le plus tĂŽt possible, c’est-Ă -dire lorsque nous pourrons considĂ©rer que notre logiciel est suffisamment stable.

N’oubliez pas que vous pouvez faire un don et financer personnellement les dĂ©veloppeurs de GIMP, afin de donner en retour et d’accĂ©lĂ©rer le dĂ©veloppement de GIMP. L’engagement de la communautĂ© aide le projet Ă  se renforcer ! đŸ’ȘđŸ„ł

Commentaires : voir le flux Atom ouvrir dans le navigateur

Des nouvelles de Unvanquished

La derniĂšre dĂ©pĂȘche sur le jeu Unvanquished a Ă©tĂ© publiĂ©e ici en 2023, pour son dixiĂšme anniversaire. La derniĂšre version annoncĂ©e ici Ă©tait la version 0.53, en 2022. Alors que nous sommes Ă  deux mois de 2025 et Ă  quelques jours de la prochaine version 0.55, c’est l’occasion de faire un point sur ce qui s’est passĂ© ces derniĂšres annĂ©es et d’ajouter un Ă©pisode Ă  la sĂ©rie « des nouvelles de [votre jeu prĂ©fĂ©rĂ©] » et de faire suite Ă  celui sur Xonotic.

Unvanquished

Laisse-moi sortir de là ! — rĂ©clame la version 0.55


Unvanquished est un jeu de stratĂ©gie en temps rĂ©el (RTS) Ă  la premiĂšre personne (FPS) oĂč des extraterrestres Ă©volutifs et des humains lourdement armĂ©s s’affrontent pour leur survie. Son dĂ©veloppement, basĂ© sur Tremulous, a commencĂ© en 2011.

Sommaire

Quelques nouvelles en vrac

Un nouveau lanceur

En prĂ©vision de la prochaine version 0.55 qui arrive (deux « release candidates » ont dĂ©jĂ  Ă©tĂ© publiĂ©es), le « lanceur » (aussi appelĂ© « updater ») a Ă©tĂ© mis Ă  jour en juillet dernier.

Le lanceur est le moyen recommandĂ© d’installer Unvanquished : il permet une intĂ©gration optimale avec le systĂšme (possibilitĂ© de cliquer sur des liens pour lancer une partie) et propose la mise Ă  jour du jeu quand une nouvelle version est disponible. Le lanceur sait aussi se mettre Ă  jour et c’est ce qui a Ă©tĂ© fait en juillet.

Des améliorations graphiques

L’annĂ©e derniĂšre le projet Unvanquished avait annoncĂ© ĂȘtre en recherche d’un dĂ©veloppeur spĂ©cialisĂ© dans les moteurs de rendus. Reaper a rejoint l’équipe et a rĂ©alisĂ© un gros travail : dĂ©bugage et finalisation des miroirs rĂ©cursifs et d’autres choses. Il fait aussi progresser le moteur pour tirer partie d’OpenGL 4.6 et autre techniques avancĂ©es (« bindless textures », etc.).

Un explorateur de serveur minimaliste

Viech a publiĂ© un explorateur de serveur de jeu minimaliste qui tient dans la barre de notification (tray browser). C’est Ă  la fois simple et pratique.

Des vidéos et un compte Mastodon

Diverses vidĂ©o montrant les avancĂ©es du dĂ©veloppement ont Ă©tĂ© publiĂ©es sur la chaĂźne Youtube d’Unvanquished, c’est l’occasion de rappeler l’existence de cette chaĂźne : https://www.youtube.com/@UNVofficial

Pour ceux qui prĂ©fĂšrent Peertube, qui permet aussi de s’abonner aux chaĂźnes Ă  travers Mastodon et plus globalement le FĂ©diverse, avec la publication de certaines parties : https://vdo.unvanquished.greboca.com/

Un compte Mastodon a Ă©tĂ© crĂ©Ă© sur l’instance idtech.space dĂ©diĂ©e aux technologies id Tech et projets associĂ©s (le moteur d’Unvanquished dĂ©rive d’id Tech 3) : https://idtech.space/users/UNVofficial

Ce compte Mastodon s’ajoute aux comptes X et Facebook. Le public libriste sera peut-ĂȘtre plus intĂ©ressĂ© par ce compte Mastodon.

Unvanquished, ARMĂ© et dangereux

De nouvelles architectures

La version 0.54 de Unvanquished sortie en janvier 2023 avait Ă©tĂ© la premiĂšre Ă  ĂȘtre jouable autrement que sur PC (x86 et x86-64), en proposant des binaires pour les processeurs ARM (sous Linux seulement pour l’instant).

CĂŽtĂ© moteur la version 0.54 avait reçu de nombreuses optimisations pour mieux tourner sur des machines moins performances, par exemple, Certaines ressources logiciels optionnelles comme les deluxemaps ne sont plus chargĂ©es si dĂ©sactivĂ©es, ceci Ă©conomise non seulement le calcul, mais aussi la mĂ©moire de la carte graphique. Les lightstyles peuvent ĂȘtre dĂ©sactivĂ©s, ce qui peut accĂ©lĂ©rer le rendu graphique, etc. La compatibilitĂ© matĂ©rielle sera encore Ă©tendue avec la version 0.55.

À partir de la version 0.54 tous les binaires pour toutes les architectures matĂ©rielles et systĂšmes d’exploitation sont compilĂ©s dans des containers Docker, y compris les binaires macOS compilĂ©s dans un container Linux en utilisant Darling, Darling Ă©tant Ă  macOS ce que Wine est Ă  Windows. La version 0.55 sera produite de la mĂȘme maniĂšre.

La version 0.55 apportera la compatibilitĂ© pour un nouveau systĂšme d’exploitation ! đŸ€«ïž

Interface, jouabilité et bots

Chargement de carte

Le nouvel Ă©cran de chargement des cartes.

L’interface avait Ă©tĂ© revue Ă  l’occasion de la version 0.54 :

  • Nouvelles icĂŽnes d’inventaire contribuĂ©es par Nanaa, Gireen et Bob Vador
    Ces icÎnes donnent un coup de fraßcheur, on distingue mieux les deux types de grenades et les armures ainsi que le mode de déplacement.
  • L’écran de chargement des cartes affiche le nom de la carte et des auteurs (si renseignĂ©) depuis les mĂ©tadonnĂ©es. Historiquement, les artistes inscrivaient ces informations sur l’image d’illustration de la carte avec un logiciel de dessin
 (!!!)
  • La version 0.55 apportera des modifications d’interface rĂ©alisĂ©es par Grise.

CĂŽtĂ© jouabilitĂ©, la version 0.54 avait corrigĂ© le momentum nĂ©gatif qui Ă©tait particuliĂšrement pĂ©nalisant. Le momentum, est gĂ©nĂ©rĂ© par les Leech (Alien) ou les Drills (Humain). Il faut qu’il y ait assez de momentum pour pouvoir construire d’autres Ă©lĂ©ments.

La version 0.54 a apportĂ© toute une sĂ©rie de nouveautĂ©s au niveau des bots (entitĂ©s qui remplacent les joueurs afin de complĂ©ter les Ă©quipes) :

  • AmĂ©lioration de l’évitement d’obstacles pour les bots.
  • Les bots peuvent viser des cibles situĂ©es sur des navmesh diffĂ©rents.
  • Certains bots n’hĂ©siteront pas Ă  sauter pour atteindre une cible en hauteur, d’autres se retiennent d’exĂ©cuter une attaque qui pourraient les blesser si la cible est trop proche


Depuis quelque temps, le dĂ©veloppement des bots suscite un regain d’intĂ©rĂȘt. La version 0.55 ne sera pas la plus riche Ă  ce sujet car elle apportera surtout des amĂ©liorations du moteur. Le dĂ©veloppement de gameplay ne s’est pas ralenti mais s’est surtout focalisĂ© sur des mods dont il faudra fusionner les avancĂ©es dans le tronc commun aprĂšs la sortie de la version 0.55. Ces amĂ©liorations de gameplay sont dĂ©jĂ  jouables sur des serveurs en ligne.

L’amĂ©lioration du comportement des bots Ă  permis un nouveau type de jeu : Le PVE. C’est Ă  dire que les joueurs peuvent jouer ensemble contre l’ennemi pilotĂ© par le serveur. Certaines cartes ont Ă©tĂ© crĂ©Ă©es spĂ©cifiquement pour ce type de jeu, et d’autres ont Ă©tĂ© adaptĂ©es Ă  l’aide de layout qui Ă©taient dĂ©jĂ  utilisĂ©s pour crĂ©er des variantes de parties.

La version 0.54.1 n’avait pas vraiment proposĂ© de modifications des donnĂ©es, il s’agissait surtout de publier des correctifs de bugs gĂȘnant du moteur. La version 0.55 viendra avec une mise Ă  jour des donnĂ©es et donc avec les corrections attendues. Par exemple un bug dans la chaĂźne logicielle de conversion d’images avait produit des artefacts dans certaines textures, ce sera corrigĂ© dans la version 0.55.

La danse des submodules

            _________________
           /                 \
          |         ✝         |  
          |                   |
          |      beloved      |
          |     submodule     |
          |                   |
          |    2017-12-30     |
          |     2023-04-11    |
          |                   |
          |       R.I.P.      |
          |                   |  đŸ„”
  (,,)Ă©   |                   |   ɘ̀(âčâč)  ɘ̀(âčâč)
////////////////////////////////////////////////

Press F to Pay Respects!

Tous ceux qui doivent traiter avec Git savent que les submodules sont trÚs pratiques mais parfois bien ennuyeux. Un travail de fond réalisé sur les outils de production des données a permis la réintégration du dossier source unvanquished_src.dpkdir. Le générateur de code CBSE qui produit la plomberie pour la logique de jeu a été réintégré aussi. Cela rend plus facile de travailler sur des mods en évitant de devoir gérer plusieurs dépÎts différents.

Contributions

Unvanquished recrute
Voulez-vous en savoir plus ?

Comme vous le voyez, ce cycle de dĂ©veloppement a aussi vu de nouveaux contributeurs apporter leur concours au projet. Certaines de leurs amĂ©liorations ont dĂ©jĂ  Ă©tĂ© publiĂ©es dans la version mineure 0.54.1, d’autres arriveront avec la version 0.55.

Récement, le développeur Slipher qui est un des développeurs Unvanquished les plus prolifiques et les plus fidÚles a étendu ses activités au moteur de rendu et a rejoint la petite élite de ceux qui savent comment le moteur fonctionne. Il a corrigé entre autre le rendu de vidéo sur des surfaces et une fonctionnalité de sprites.

La liste de rĂ©gressions depuis le dĂ©sormais lointain ancĂȘtre d’Unvanquished, Tremulous, est maintenant rĂ©duite Ă  peau de chagrin.

Des traductions !

La grosse nouveautĂ© de la version 0.54.1 publiĂ©e en dĂ©cembre 2023 a Ă©tĂ© de proposer Ă  nouveau des traductions intĂ©grĂ©es au jeu. L’outil de traduction est gracieuseuement hĂ©bergĂ© par Weblate.

L’interface Weblate

L’interface de traduction Weblate.

Il y a longtemps, le jeu Ă©tait traduit, mais suite Ă  de trĂšs profonds changements (par exemple le remplacement total de la technologie utilisĂ©e pour faire des menus, dĂ©sormais sous RmlUi), l’effort de traduction avait Ă©tĂ© interrompu.

La traduction francophone est bien avancĂ©e, mais la traduction en breton a besoin de plus de contributions. Si vous souhaitez contribuer votre langue rĂ©gionale, vous ĂȘtes les bienvenus, c’est ici que cela se passe !

La 0.55 arrive !

Préparez votre souris et votre clavier, la version 0.55 arrive trÚs bientÎt.

Commentaires : voir le flux Atom ouvrir dans le navigateur

Haiku a 23 ans - Haiku R1 bĂȘta 5 (partie 1 : applications)

Haiku est un systĂšme d’exploitation libre destinĂ© aux ordinateurs personnels ou de bureau (pas de serveurs, pas de systĂšmes embarquĂ©s, pas de tablettes ni de tĂ©lĂ©phones). Il s’agit au dĂ©part d’une rĂ©Ă©criture libre de BeOS, prĂ©servant la compatibilitĂ© binaire avec ce dernier (les applications BeOS peuvent tourner sur certaines versions de Haiku).

Le projet Haiku (au dĂ©part nommĂ© OpenBeOS) a dĂ©marrĂ© officiellement le 18 aoĂ»t 2001 avec le premier message sur la liste de diffusion : Ok, let's start (OK, allons-y). Cet anniversaire est l’occasion de faire un point sur les dĂ©veloppements de l’annĂ©e dans Haiku et ce qui est en prĂ©paration.

La dĂ©pĂȘche a Ă©tĂ© un peu retardĂ©e cette annĂ©e, pour ĂȘtre synchronisĂ©e avec la version R1 bĂȘta 5 de Haiku, publiĂ©e le vendredi 13 septembre 2024.

Le projet emploie un dĂ©veloppeur presque Ă  plein temps depuis 2021 et le reste de l’équipe contribue bĂ©nĂ©volement. La derniĂšre version bĂȘta a Ă©tĂ© publiĂ©e fin 2023 et la BĂȘta 5 est dĂ©sormais disponible : l’occasion de revenir en trois parties sur ce que propose Haiku, d’abord des applications, un noyau et des amĂ©liorations de la documentation.

Sommaire

PrĂšs de 350 tickets ont Ă©tĂ© clos dans le cadre du travail sur la version R1 bĂȘta 5. Il y a bien sĂ»r de trĂšs nombreuses corrections de bugs, qui ne seront pas listĂ©es dans cet article. On se concentrera plutĂŽt sur les nouveautĂ©s, sauf dans les cas oĂč la correction est vraiment importante ou permet d’ouvrir de nouvelles possibilitĂ©s d’utilisation.

Applications

Haiku est un systĂšme d’exploitation complet, fourni avec un certain nombre d’applications permettant d’accomplir les tĂąches les plus courantes. En plus de ces applications de base, le gestionnaire de paquets HaikuDepot, alimentĂ© principalement par le travail du projet HaikuPorts, apporte Ă  la fois des applications portĂ©es depuis d’autres systĂšmes et des applications dĂ©veloppĂ©es spĂ©cifiquement pour Haiku.

De façon gĂ©nĂ©rale, on trouve cette annĂ©e dans les applications de Haiku des amĂ©liorations sur le rendu des nombres, l’utilisation d’un symbole de multiplication Ă  la place d’une lettre x lĂ  oĂč c’est pertinent, et de nombreuses petites corrections et amĂ©liorations sur la mise en page des fenĂȘtres, des corrections de problĂšmes de traduction et ainsi de suite.

AboutSystem

AboutSystem est la fenĂȘtre d’information sur le systĂšme Haiku. Elle fournit quelques informations sur la machine sur laquelle le systĂšme fonctionne (quantitĂ© de RAM, marque et modĂšle du CPU, uptime) ainsi que les noms des dĂ©veloppeurs et autres logiciels libres ayant participĂ© au dĂ©veloppement de Haiku.

Cette application reçoit tout d’abord une mise Ă  jour cosmĂ©tique : si le systĂšme est configurĂ© en « mode sombre », le logo Haiku correspondant (avec un lettrage blanc et des dĂ©gradĂ©s de couleurs un peu diffĂ©rents) sera utilisĂ©. Sinon, ce sera le logo avec lettrage noir.

AboutSystem en mode clair
AboutSystem en mode sombre

Elle reçoit Ă©galement quelques mises Ă  jour de contenu : en plus de l’ajout de quelques nouveaux contributeurs qui ont rejoint le projet, on trouvera maintenant un lien vers la page web permettant de faire un don Ă  Haiku. Plusieurs liens vers des bibliothĂšques tierces utilisĂ©es dans Haiku, qui ne fonctionnaient plus, ont Ă©tĂ© soit supprimĂ©s, soit remplacĂ©s par des liens mis Ă  jour.

Enfin, il est dĂ©sormais possible d’utiliser AboutSystem comme un « rĂ©plicant », c’est-Ă -dire de l’installer directement sur le bureau pour avoir en permanence sous les yeux les statistiques sur l’utilisation mĂ©moire et l’uptime ainsi que le numĂ©ro de build de Haiku en cours d’exĂ©cution (ce qui peut ĂȘtre utile par exemple lorsqu’on lance beaucoup de machines virtuelles avec des versions diffĂ©rentes de Haiku pour comparer un comportement, ou si on veut stocker des captures d’écran de plusieurs versions et s’y retrouver facilement).

CharacterMap

L’application « table de caractĂšres » permet d’étudier de prĂšs les diffĂ©rents glyphes et symboles prĂ©sents dans une police de caractĂšres. En principe, elle permet de choisir une police spĂ©cifique, mais le serveur graphique de Haiku substitue automatiquement une autre police si on lui demande d’afficher un caractĂšre qui n’est pas disponible dans la police demandĂ©e.

Cela peut ĂȘtre gĂȘnant dans certains contextes, par exemple si on envisage d’embarquer une police dans un fichier PDF, il est difficile de savoir quelle police contient vraiment les caractĂšres qu’on veut utiliser.

L’application a Ă©tĂ© amĂ©liorĂ©e pour traiter ce cas et affiche maintenant ces caractĂšres en grisĂ©.

CharacterMap affichant des caractĂšres manquants

CodyCam

CodyCam est une application permettant de tester une webcam et de l’utiliser pour envoyer pĂ©riodiquement des images vers un serveur HTTP.

L’évolution principale a Ă©tĂ© la mise Ă  jour de l’icĂŽne de l’application. L’utilitĂ© de CodyCam est limitĂ©e par le manque de pilotes : il faudra soit trouver une webcam Sonix du dĂ©but des annĂ©es 90, seul modĂšle USB Ă  disposer d’un pilote fonctionnel, soit utiliser un ordiphone Android Ă©quipĂ© d’un logiciel permettant de le transformer en camĂ©ra IP (ou encore une vraie camĂ©ra IP).

Le pilote pour les WebCams UVC — standard utilisĂ© pour les camĂ©ras USB modernes — n’est pas encore au point et n’est pas inclus dans les versions publiĂ©es de Haiku.

Debugger

Debugger est, comme son nom l’indique, le debugger de Haiku. Il est dĂ©veloppĂ© spĂ©cifiquement pour le projet sans s’appuyer sur les outils existants (gdb ou lldb). Il dispose Ă  la fois d’une interface graphique et d’une interface en ligne de commande, plus limitĂ©e. Cette derniĂšre est surtout utilisĂ©e pour investiguer des problĂšmes dans les composants de Haiku qui sont nĂ©cessaires pour l’utilisation d’une application graphique : app_server, input_server ou encore registrar.

La version en ligne de commande a reçu quelques petites amĂ©liorations, mais la principale nouveautĂ© est la prise en charge des formats DWARF-4 et DWARF-5 pour les informations de debug. Cela permet de charger les informations gĂ©nĂ©rĂ©es par les versions modernes de GCC, sans avoir besoin de forcer la gĂ©nĂ©ration d’une version plus ancienne du format DWARF.

Le dĂ©sassembleur udis86, qui n’est plus maintenu et ne reconnaĂźt pas certaines instructions ajoutĂ©es rĂ©cemment dans les processeurs x86, a Ă©tĂ© remplacĂ© par Zydis.

Enfin, un bug assez gĂȘnant a Ă©tĂ© corrigé : si une instance de Debugger Ă©tait dĂ©jĂ  en train de dĂ©bugger une application et qu’une deuxiĂšme application venait Ă  planter, il n’était pas possible d’attacher une deuxiĂšme instance de Debugger Ă  cette application. Les problĂšmes impliquant plusieurs processus pouvaient donc ĂȘtre un peu compliquĂ©s Ă  investiguer. C’est maintenant rĂ©solu.

Deskbar

L’application DeskBar fournit la « barre des tĂąches » de Haiku. Elle permet de naviguer entre les fenĂȘtres et applications ouvertes, de lancer de nouvelles applications via un menu (similaire au « menu dĂ©marrer » de Windows), ou encore d’afficher une horloge et des icĂŽnes fournis par d’autres applications (sous forme de rĂ©plicants).

Elle fait partie, avec le Tracker, des applications qui ont Ă©tĂ© publiĂ©es sous license libre lors de l’abandon de BeOS par Be Inc.

Quelques changements dans la DeskBar :

  • Tous les menus utilisent maintenant la police « menu » choisie dans les prĂ©fĂ©rences d’apparence du systĂšme. Auparavant, la police « menu » et la police « plain » Ă©taient mĂ©langĂ©es. Ces deux polices Ă©tant identiques dans la configuration par dĂ©faut, le problĂšme n’avait pas Ă©tĂ© repĂ©rĂ©.
  • Si un nom de fenĂȘtre est tronquĂ© dans la liste des fenĂȘtres, le nom complet peut ĂȘtre affichĂ© dans une infobulle.
  • L’icĂŽne pour les fenĂȘtres dans la DeskBar a Ă©tĂ© remplacĂ©e. La nouvelle icĂŽne indique plus clairement si une fenĂȘtre se trouve dans un autre bureau virtuel (dans ce cas, activer cette fenĂȘtre provoquera un changement de bureau).

GLTeapot

GLTeapot est une application permettant de tester le rendu OpenGL, en affichant un modĂšle 3D de la thĂ©iĂšre de l’Utah.

En plus de la thĂ©iĂšre, cette application affiche un compteur du nombre d’images affichĂ©es par secondes. Bien que les chiffres affichĂ©s ne soient pas du tout reprĂ©sentatifs des performances d’un rendu 3D rĂ©aliste, certains utilisateurs insistent lourdement pour pouvoir faire le concours de gros chiffres de nombre d’images par seconde.

Il est donc Ă  nouveau possible de dĂ©sactiver la synchronisation sur le rafraĂźchissement de l’écran, et demander au processeur de rĂ©afficher la thĂ©iĂšre plusieurs centaines de fois par seconde, bien que l’écran soit incapable de suivre le rythme. Par dĂ©faut, la synchronisation est activĂ©e et le rafraĂźchissement ne dĂ©passera jamais 60 FPS, si toutefois le pilote graphique implĂ©mente les fonctions de synchronisation nĂ©cessaires.

HaikuDepot

HaikuDepot est un hybride entre un gestionnaire de paquets et un magasin d’applications.

Il se compose d’un serveur (dĂ©veloppĂ© en Java) fournissant une API REST et permettant de collecter les informations sur les applications (icĂŽnes, captures d’écrans, catĂ©gories, votes et revues des utilisateurs, choix de la rĂ©daction pour les applications mises en avant
), d’un frontend web minimaliste et d’une application native C++ permettant d’afficher ces donnĂ©es.

La principale nouveautĂ© est l’intĂ©gration du systĂšme de single-sign-on (SSO) permettant d’utiliser un compte utilisateur commun avec d’autres services en ligne de Haiku. Actuellement, l’outil de revue de code Gerrit
utilise ce mĂȘme compte, mais ce n’est pas encore le cas pour Trac (outil de suivi des bugs) ni pour le forum. Ce sera mis en place plus tard.

De façon peut-ĂȘtre moins visible, mais pas moins importante, le code C++ de l’application a reçu de nombreuses amĂ©liorations et optimisations « sous le capot », rendant l’application plus rapide et plus fiable, mais qui sont un peu difficiles Ă  rĂ©sumer dans le cadre de cette dĂ©pĂȘche.

Enfin, l’apparence de l’application a Ă©tĂ© lĂ©gĂšrement retravaillĂ©e pour mieux s’adapter aux Ă©crans Ă  haute dĂ©finition (ce qui nĂ©cessite d’avoir des marges et espacements de taille dynamique en fonction de la taille de texte choisie par l’utilisateur).

Icon-O-Matic

Capture d’écran de l’éditeur d’icĂŽnes

Icon-O-Matic est un Ă©diteur d’icĂŽnes. Il permet d’exporter les fichiers au format HVIF, un format vectoriel compact qui permet de stocker les icĂŽnes dans l’inode d’en-tĂȘte des fichiers pour un chargement et un affichage rapide.

Cette application a bĂ©nĂ©ficiĂ© du travail de Zardshard pendant le Google Summer of Code 2023, elle a donc reçu plusieurs Ă©volutions et corrections importantes (dont certaines sont mentionnĂ©es dans la dĂ©pĂȘche anniversaire de l’annĂ©e derniĂšre).

Citons en particulier l’ajout d’un nouveau type de transformation, « perspective », qui permet de facilement dĂ©former un ensemble de chemins vectoriels selon une projection de perspective, ce qui est assez utile pour concevoir plus facilement une icĂŽne avec un aspect tridimensionnel (bien qu’en pratique l’apparence habituelle des icĂŽnes de Haiku soit un intermĂ©diaire entre une projection perspective et une vue isomĂ©trique, ne se prĂȘtant pas forcĂ©ment Ă  l’utilisation de cette opĂ©ration de transformation purement mathĂ©matique).

Une autre petite amĂ©lioration est l’ajout d’une vĂ©rification pour empĂȘcher la fenĂȘtre de Icon-O-Matic de se positionner en dehors de l’écran, par exemple si on a dĂ©placĂ© la fenĂȘtre vers le bas de l’écran, enregistrĂ© cette position, puis relancĂ© l’application dans une rĂ©solution d’écran plus rĂ©duite. Dans ce cas, la fenĂȘtre sera automatiquement ramenĂ©e dans la zone visible de l’affichage.

Magnify

L’application Magnify permet d’afficher une vue zoomĂ©e d’une partie de l’écran. Elle peut servir pour amĂ©liorer l’accessibilitĂ© (mais n’est pas idĂ©ale pour cet usage), mais aussi pour les dĂ©veloppeurs d’interfaces graphiques qui ont parfois besoin de compter les pixels pour s’assurer que leurs fenĂȘtres sont bien construites.

En plus de l’affichage zoomĂ©, l’application permet d’afficher l’encodage RGB de la couleur d’un pixel, ou encore de placer des « rĂšgles » permettant de vĂ©rifier l’alignement des objets. Ces derniĂšres ont reçu une petite mise Ă  jour, avec une amĂ©lioration de l’affichage de leur largeur et hauteur pour les rendre plus lisibles.

Magnify avec une 'rĂšgle'

MediaPlayer

L’affichage des sous-titres ne fonctionnait pas correctement, il manquait une partie du texte. C’est maintenant corrigĂ©.

PowerStatus

Capture d’écran de PowerStatus: fenĂȘtre principale et icĂŽne de la DeskBar avec son menu

L’application PowerStatus permet de surveiller l’état de la batterie pour les ordinateurs qui en disposent.

Elle a reçu plusieurs améliorations importantes :

Une notification a Ă©tĂ© ajoutĂ©e pour un niveau de dĂ©charge trĂšs faible (en plus du niveau faible dĂ©jĂ  prĂ©sent). Ces deux niveaux peuvent ĂȘtre paramĂ©trĂ©s Ă  un pourcentage choisi de dĂ©charge de la batterie, et associĂ© Ă  des sons d’alerte spĂ©cifiques. Avant ces changements, il Ă©tait facile de ne pas voir le message d’alerte (affichĂ© seulement pendant quelques secondes) ou de se dire qu’avec 15% de batterie on a encore le temps de faire plein de trucs, puis se retrouver un peu plus tard avec une batterie vide sans autre avertissement.

L’état « not charging » est maintenant dĂ©tectĂ© et correctement affichĂ©, pour une batterie au repos : ni en train de se charger, ni en train d’alimenter la machine. C’est en particulier le cas d’une batterie dĂ©jĂ  chargĂ©e Ă  100%, si la machine reste connectĂ©e au rĂ©seau Ă©lectrique.

L’icĂŽne de statut de la batterie s’installe automatiquement dans la DeskBar au premier dĂ©marrage de Haiku sur les machines disposant d’une batterie.

Le rĂ©glage du mode « performance » ou « économie d’énergie" est enregistrĂ© et rĂ©-appliquĂ© lors des prochains dĂ©marrages (ces modes configurent l’ordonnanceur du noyau pour exĂ©cuter un maximum de tĂąches sur tous les cƓurs du processeur, ou bien au contraire pour essayer de garder ces cƓurs en veille autant que possible s’ils ne sont pas nĂ©cessaires).

SerialConnect

SerialConnect est une application de terminal série, utile principalement aux développeurs de systÚmes embarqués et autres gadgets électroniques.

Elle est encore en cours de dĂ©veloppement et propose pour l’instant les fonctions les plus basiques. Il est maintenant possible de coller du texte depuis le presse-papier pour l’envoyer sur un port sĂ©rie, ce qui est pratique si on veut envoyer plusieurs fois la mĂȘme sĂ©quence de commandes.

ShowImage

ShowImage est la visionneuse d’images de Haiku. Elle utilise les traducteurs, des greffons avec une API standardisĂ©e qui permettent de convertir diffĂ©rents formats de fichiers entre eux.

L’interface graphique de ShowImage a Ă©tĂ© mise Ă  jour pour utiliser le « layout system ». Historiquement, dans BeOS, tous les Ă©lĂ©ments des interfaces graphiques devaient ĂȘtre positionnĂ©s manuellement avec des coordonnĂ©es en pixels, ce qui est pĂ©nible Ă  faire, surtout si on doit traiter tous les cas (polices de caractĂšres de diffĂ©rentes tailles, remplacement des textes lors de traductions, utilisation de thĂšme d’interfaces diffĂ©rents), et aussi lors d’évolution de l’application (si on veut insĂ©rer un Ă©lĂ©ment en plein milieu, il faut souvent dĂ©caler tout ce qui se trouve autour).

Le « layout system » fournit un ensemble d’outils pour automatiser ce travail, soit Ă  l’aide d’élĂ©ments prĂ©dĂ©finis (grilles, groupes, « cartes » superposĂ©es), soit Ă  l’aide d’un systĂšme de dĂ©finition de contraintes et de programmation linĂ©aire.

D’autre part, ShowImage dispose maintenant d’un menu permettant d’ouvrir l’image affichĂ©e dans un Ă©diteur d’images.

Terminal

Le Terminal de Haiku permet d’exĂ©cuter un shell (c’est bash par dĂ©faut) et toutes les applications conçues pour un affichage en console.

Les principaux changements cette annĂ©e sont la correction d’un problĂšme sur la configuration des couleurs utilisĂ©es par le Terminal (il y avait un mĂ©lange entre le nom anglais et le nom traduit des couleurs, empĂȘchant d’enregistrer et de relire correctement le fichier de configuration), ainsi que des modifications sur les raccourcis clavier utilisĂ©s par le Terminal lui-mĂȘme (en particulier pour naviguer entre plusieurs onglets) qui entraient en conflit avec ceux utilisĂ©s par les applications lancĂ©es dans le terminal.

Le terminal est Ă©galement capable de traiter les « bracketed paste », c’est-Ă -dire que les applications en console sont informĂ©es que des caractĂšres en entrĂ©e proviennent du presse-papier. Cela permet par exemple Ă  bash de ne pas exĂ©cuter directement des commandes qui sont collĂ©es, mais de les mettre en surbrillance et d’attendre que l’utilisateur valide cette saisie.

D’un point de vue plus bas niveau, les pilotes TTY utilisĂ©s pour les ports sĂ©rie et pour le Terminal, qui Ă©taient indĂ©pendants, ont Ă©tĂ© unifiĂ©s afin d’éviter de devoir corriger tous les bugs deux fois dans deux versions du code presque identiques.

Tracker

Tracker est le navigateur de fichiers de Haiku. Tout comme la DeskBar, il fait partie des quelques rares morceaux de BeOS qui ont Ă©tĂ© publiĂ©s sous licence libre par Be et ont donc pu ĂȘtre repris directement par Haiku. Contrairement Ă  la DeskBar, la publication du code du Tracker avait conduit Ă  l’apparition de nombreux forks, chacun amĂ©liorant Ă  sa façon le logiciel. La version utilisĂ©e par Haiku provient principalement du projet OpenTracker, mais a rĂ©intĂ©grĂ© ou rĂ©implĂ©mentĂ© au fil du temps les modifications faites dans d’autres variantes.

Le Tracker est un composant central de l’interface de Haiku et a donc reçu un nombre assez important d’évolutions :

La taille des fichiers est maintenant affichĂ©e Ă  l’aide de la fonction string_for_size qui s’adapte aux conventions de la langue et du pays choisi par l’utilisateur.

Les brouillons de courrier Ă©lectronique disposent maintenant de leur propre type MIME et de l’icĂŽne associĂ©e. Ils s’ouvriront dans un Ă©diteur de mail plutĂŽt que dans une fenĂȘtre de lecture de message.

Pour les fichiers qui disposent d’un attribut « rating » (Ă©valuation), ce dernier est affichĂ© avec des Ă©toiles pleines ou vides selon la note attribuĂ©e. La note va de 0 Ă  10 mais il n’y a que 5 Ă©toiles. Le caractĂšre demi-Ă©toile permet d’afficher la note exacte avec les versions rĂ©centes d’Unicode (depuis 2018 en fait, mais il a fallu attendre la disponibilitĂ© dans une police de caractĂšres).

Une fenĂȘtre du Tracker, montrant la colonne taille et la colonne rating

La gestion des dossiers en lecture seule a Ă©tĂ© amĂ©liorĂ©e. Ils sont affichĂ©s sur fond gris (au lieu d’un fond blanc pour les dossiers modifiables) et tous les menus correspondant Ă  des opĂ©rations non autorisĂ©es sont dĂ©sactivĂ©s (au lieu d’ĂȘtre activĂ©s, mais d’aboutir sur une erreur car le dossier est en lecture seule).

Dans le mĂȘme esprit, le bouton « ouvrir » des boĂźtes de dialogues d’ouverture de fichier est dĂ©sactivĂ© si le fichier sĂ©lectionnĂ© ne peut pas ĂȘtre ouvert (c’était dĂ©jĂ  le cas, mais tous les cas possibles n’étaient pas bien pris en compte).

Un problĂšme d’affichage sur le systĂšme de fichier packagefs a Ă©tĂ© corrigĂ© : les dossiers n’ont pas de taille et affichent donc - au lieu d’une taille fixe de 4 Kio qui n’a aucune signification.

La fenĂȘtre de recherche a reçu quelques Ă©volutions, voir plus bas dans la section dĂ©diĂ©e au Google Summer of Code, qui dĂ©taille le travail rĂ©alisĂ© Ă  ce sujet.

Le menu « templates », utilisĂ© quand on fait un 'clic droit -> Nouveau
' et qui permet de crĂ©er diffĂ©rents types de fichiers et de dossiers Ă  partir de fichiers de rĂ©fĂ©rence, peut maintenant contenir des sous-dossiers, pour les personnes qui utilisent beaucoup cette possibilitĂ©, avec par exemple des modĂšles de documents prĂ©-remplis pour diffĂ©rents usages.

Enfin, un peu de nettoyage interne : les classes NavMenu et SlowContextPopup, qui permettent la navigation dans les sous-dossiers via des menus popup, ont Ă©tĂ© fusionnĂ©es en une seule classe car elles sont toujours utilisĂ©es ensemble. Cela simplifie le code pour l’affichage de ces menus, qui a quelques particularitĂ©s pour permettre une navigation confortable mĂȘme sur un disque dur un peu lent.

TV

L’application TV utilisĂ©e pour recevoir la TNT Ă  l’aide d’un tuner appropriĂ© a Ă©tĂ© dĂ©placĂ©e dans le paquet haiku_extras et n’est donc plus installĂ©e par dĂ©faut. La plupart des gens ne disposant pas d’un tuner compatible sur leur ordinateur, cette application Ă©tait source de confusion et de nombreuses questions sur le forum.

WebPositive

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

En dehors de la mise Ă  jour du moteur vers une version plus rĂ©cente, WebPositive reçoit actuellement peu d’évolutions, les dĂ©veloppeurs Ă©tant malheureusement trop occupĂ©s par ailleurs. On peut toutefois mentionner une correction sur la barre de signets : celle-ci ne s’affichait jamais lorsque la langue du systĂšme Ă©tait autre chose que l’anglais.

Zip-O-Matic

Zip-O-Matic est un outil permettant de crĂ©er une archive zip facilement depuis le Tracker. Il a reçu une amĂ©lioration qui est en fait une correction d’un problĂšme qui existait depuis longtemps : l’archive crĂ©Ă©e est maintenant automatiquement sĂ©lectionnĂ©e dans le navigateur de fichier Ă  la fin du processus, ce qui permet de facilement la retrouver pour la renommer, la dĂ©placer ou l'envoyer Ă  son destinataire.

Haikuports

Haikuports est un projet indĂ©pendant de Haiku, il se charge d’alimenter le dĂ©pĂŽt de paquets. Au dĂ©part il s’agissait principalement d’un projet pour le portage de bibliothĂšque et de programmes venant d’autres systĂšmes (d’oĂč son nom), mais il est Ă©galement utilisĂ© pour la plupart des applications natives dĂ©veloppĂ©es pour Haiku.

Le dĂ©pĂŽt de paquets contient actuellement 4193 paquets, il est mis Ă  jour en continu par une petite Ă©quipe de bĂ©nĂ©voles qui ne sont pas forcĂ©ment tous dĂ©veloppeurs, mais tout de mĂȘme capables de faire les tĂąches de maintenance ainsi que le dĂ©veloppement de quelques patchs simples.

Il est impossible de lister toutes les mises à jour et ajouts, le projet HaikuPorts étant trÚs actif. Donc voici une sélection arbitraire de quelques nouveautés et mises à jour.

Applications natives

  • Mises Ă  jour de Renga (client XMPP), PonpokoDiff (outil de diff), 2pow (clone de 2048), StreamRadio (lecteur de podcasts), NetSurf (navigateur web lĂ©ger)

  • Genio, un IDE pour Haiku avec gestion de la complĂ©tion de code via le protocole LSP (compatible avec les outils dĂ©veloppĂ©s pour VS Code par exemple).
  • Ajout de HaikuUtils, un ensemble d’outils de dĂ©veloppement et de debug divers.
  • WorkspaceNumber, un replicant pour afficher le numĂ©ro du bureau actif dans la DeskBar.
  • KeyCursor, un outil pour contrĂŽler le curseur de souris Ă  l’aide du clavier.
  • BatchRename, un outil pour renommer automatiquement des fichiers par lot.

HaikuUtils

WorkspaceNumber

PonpokoDiff

PecoRename

2pow

BatchRename

Applications portées

  • Un gros travail a Ă©tĂ© fait sur le portage de KDE Frameworks et des applications l’utilisant. De trĂšs nombreuses applications Qt et KDE sont donc disponibles.
  • Du cĂŽtĂ© de GTK, il n’existait pas de version de GTK pour Haiku, le problĂšme a Ă©tĂ© rĂ©solu Ă  l’aide d’une couche de compatibilitĂ© avec Wayland qui n’implĂ©mente pas le protocole Wayland mais rĂ©implĂ©mente l’API de la libwayland. Les applications GTK arrivent petit Ă  petit, mais l’intĂ©gration est pour l’instant beaucoup moins bonne qu’avec Qt, qui dispose lui d’un vrai port utilisant les APIs natives directement. L’apparence des applications est trĂšs visiblement diffĂ©rente, certaines touches du clavier ne fonctionnent pas. C’est donc encore un peu expĂ©rimental.
  • Enfin, pour complĂ©ter les possibilitĂ©s d’outils graphiques, la bibliothĂšque Xlibe implĂ©mente les APIs de la libx11 (mais pas le protocole de communication de X) et permet de porter les applications FLTK par exemple, ainsi que celles utilisant directement la libx11. Il reste encore des problĂšmes avec les applications utilisant Tk (si vous connaissez Tk ou X, les dĂ©veloppeurs de Xlibe aimeraient bien un petit coup de main). En attendant, les applications Tk sont utilisables Ă  travers un portage de undroidwish, mais ça reste peu confortable.

Du cĂŽtĂ© des compilateurs et des langages de programmation : LLVM a Ă©tĂ© mis Ă  jour en version 17. GCC est disponible en version 13 et peut maintenant ĂȘtre utilisĂ© pour compiler du FORTRAN et de l’Objective-C. Les derniĂšres versions de Python sont disponibles, et en plus avec des performances amĂ©liorĂ©es. Node.JS est Ă©galement mis Ă  jour, ou si vous prĂ©fĂ©rez le langage R, vous le trouverez Ă©galement, avec son IDE associĂ© rkward.

Bien sĂ»r, la plupart des bibliothĂšques et outils disponibles sur d’autres systĂšmes sont aussi disponibles : ffmpeg (en version 6), Git, libreoffice, Wireshark


Mentionnons enfin un pilote FUSE pour monter des volumes réseau NFS, qui vient compléter les deux implémentations de NFS présentes dans le noyau (une obsolÚte qui implémente NFS2, et une plus récente implémentant NFS4, mais qui est instable et pas activement maintenue actuellement).

GCompris

DrawTerm

KDE Mah Jong

NetBeans

Frogatto

CudaText

Cantor

Panneaux de préférences

Appearance

Les prĂ©fĂ©rences « Appearance » permettent de configurer l’apparence du systĂšme et des applications : principalement les polices de caractĂšres et les choix de couleurs.

C’est ce dernier qui reçoit une mise Ă  jour en profondeur, avec l’ajout d’un mode automatique. Auparavant, chaque couleur utilisĂ©e par le systĂšme devait ĂȘtre configurĂ©e manuellement, ce qui permet un contrĂŽle trĂšs fin, mais demande de passer un certain temps Ă  faire des ajustements. Le mode automatique permet de configurer seulement 3 couleurs : le fond des fenĂȘtres, les barres de titres, et une couleur d’« accentuation ». Les autres couleurs et nuances sont calculĂ©es automatiquement Ă  partir de cette palette de base.

En particulier, il devient beaucoup plus facile de choisir un fond sombre pour se retrouver avec un systÚme en mode sombre, trÚs à la mode chez certain·e·s utilisateurices de Haiku.

Il est toujours possible d’activer le mode avancĂ© pour affiner les rĂ©glages si nĂ©cessaire (ou si vous aimez les interfaces graphiques bariolĂ©es et multicolores).

Le mode automatique dans l’application Appearance

La mĂȘme capture d’écran avec une configuration « mode sombre »

Keymap (disposition clavier)

L’application Keymap permet de configurer la disposition de touches du clavier. Le point qui a reçu un peu d’attention est la gestion de la configuration des touches modificatrices.

Haiku est un dĂ©rivĂ© de BeOS qui lui-mĂȘme a Ă©tĂ© au dĂ©part inspirĂ© de Mac OS. On conserve de cet hĂ©ritage l’utilisation des touches commande et option au lieu de meta et alt sur les claviers de PC. Mais BeOS et Haiku sont conçus pour ĂȘtre utilisĂ©s avec des claviers de PC. La touche commande qui prend la place de la touche ALT est donc celle utilisĂ©e pour la plupart des raccourcis claviers. Cela se complique si on essaie d’utiliser un clavier fabriquĂ© par Apple (les codes de touches renvoyĂ©s par le clavier pour des touches situĂ©es au mĂȘme endroit ne sont pas les mĂȘmes), ou encore si on a besoin d’une touche AltGr (historiquement utilisĂ©e comme touche option par BeOS, mais aujourd’hui ce rĂŽle est plutĂŽt attribuĂ© Ă  la touche windows apparue un peu plus tard). Une page sur le wiki de dĂ©veloppement de Haiku tente de rĂ©sumer l’historique et la situation actuelle.

La configuration des touches modificatrices est donc un sujet complexe, et il est probable que le comportement sera Ă  nouveau modifiĂ© plus tard. Quoi qu’il en soit, en attendant, l’application Keymap permet toutes les permutations possibles de configuration de ces touches.

Screen (Affichage)

Les prĂ©fĂ©rences d’affichage, en plus de permettre de changer la rĂ©solution d’écran, affichent quelques informations essentielles sur la carte graphique et l’écran en cours d’utilisation. Pour les Ă©crans, ces informations sont gĂ©nĂ©ralement extraites des donnĂ©es EDID, mais il y a une exception : les dalles d’affichage des PC portables n’implĂ©mentent en gĂ©nĂ©ral pas ce protocole. Les informations sont donc rĂ©cupĂ©rĂ©es par d’autres moyens parfois moins bien normalisĂ©s. Par exemple, l’identifiant du fabricant est un code Ă  3 lettres. En principe, les fabricants doivent s’enregistrer auprĂšs d’un organisme qui attribue ces codes, afin d’en garantir l’unicitĂ©.

Cependant, certains fabricants ne l’ont pas fait, et se sont choisi eux-mĂȘmes un code qui semblait inutilisĂ©. La base de donnĂ©es officielle rĂ©serve donc ces codes et en interdit l’utilisation, afin d’éviter des conflits. Il arrivait donc que le fabriquant d’un Ă©cran soit affichĂ© comme Ă©tant « DO NOT USE », ce qui a inquiĂ©tĂ© quelques utilisateurs de Haiku se demandant s’ils risquaient d’endommager leur matĂ©riel.

Ces entrĂ©es de la liste sont maintenant filtrĂ©es et remplacĂ©es par les noms des fabricants de panneaux d’affichages concernĂ©s (lorsqu’on sait de qui il s’agit).

Outils en ligne de commande

Haiku est fourni avec un terminal et un shell bash (par dĂ©faut, d’autres shells peuvent Ă©galement ĂȘtre utilisĂ©s). Les outils dĂ©finis dans la spĂ©cification POSIX sont fournis, ainsi que des complĂ©ments permettant d’utiliser les fonctionnalitĂ©s supplĂ©mentaires de Haiku.

df

La commande df affiche l’espace disque disponible sur chaque volume de stockage actuellement montĂ©.

Les colonnes de l’affichage ont Ă©tĂ© rĂ©organisĂ©es, pour ĂȘtre plus lisibles, et se rapprocher un peu du format spĂ©cifiĂ© par POSIX (mais pas complĂštement lorsqu’on lance la commande sans options particuliĂšres : des informations supplĂ©mentaires sont alors affichĂ©es).

filteredquery

L’outil filteredquery permet d’effectuer une requĂȘte sur les attributs Ă©tendus du systĂšme de fichiers (permettant de requĂȘter le systĂšme de fichiers comme une base de donnĂ©es, plutĂŽt que de naviguer de façon hiĂ©rarchique dans les dossiers), puis de filtrer le rĂ©sultat pour ne conserver que les rĂ©ponses contenues dans un sous-dossier spĂ©cifique. En effet, les requĂȘtes Ă©tant indĂ©pendantes de l’organisation des dossiers, il est nĂ©cessaire de faire ce filtrage par post-traitement des rĂ©sultats (ce qui reste tout de mĂȘme gĂ©nĂ©ralement plus rapide que de faire l’inverse : parcourir tous les fichiers d’un dossier pour trouver ceux correspondant Ă  un critĂšre particulier).

Cet outil n’a pas reçu de nouvelles fonctionnalitĂ©s, mais de nombreuses corrections et nettoyages qui le rendent vĂ©ritablement utilisable.

ping, traceroute, telnet, ftpd

Ces commandes liĂ©es Ă  des opĂ©rations sur le rĂ©seau ont Ă©tĂ© remplacĂ©es par les derniĂšres versions dĂ©veloppĂ©es par FreeBSD, permettant de bĂ©nĂ©ficier d’une version moderne, avec plus de fonctionnalitĂ©s et moins de bugs.

La commande ping6 est supprimĂ©e, car ping peut maintenant utiliser l’IPv6 aussi bien que l’IPv4.

pkgman

L’outil pkgman permet de tĂ©lĂ©charger et d’installer des logiciels et des mises Ă  jour.

Il a peu Ă©voluĂ©, mais on peut tout de mĂȘme noter l’utilisation d’un algorithme de tri « naturel » pour l’affichage des rĂ©sultats dans l’ordre alphabĂ©tique (par exemple, llvm12 sera affichĂ© aprĂšs llvm9).

Une fonction qui n’est toujours pas disponible dans pkgman est le nettoyage des dĂ©pendances non utilisĂ©es. Un script fourni dans le dĂ©pĂŽt Git de Haiku permet de rĂ©aliser manuellement une analyse des paquets installĂ©s sur le systĂšme pour dĂ©tecter ceux qui n’ont pas de dĂ©pendances, il faudra pour l’instant se contenter de cette solution.

strace

L’outil strace permet d’afficher les appels systĂšmes effectuĂ©s par une application, pour comprendre son interfaçage avec le noyau et investiguer certains problĂšmes de performances ou de mauvais comportements.

L’interfaçage avec le noyau pour extraire ces informations Ă©tant assez spĂ©cifique, l’implĂ©mentation de strace est faite Ă  partir de zĂ©ro, et ne partage pas de code avec la commande du mĂȘme nom disponible par exemple sous Linux.

strace est mis Ă  jour rĂ©guliĂšrement et en fonction des besoins des dĂ©veloppeurs de Haiku pour dĂ©coder et afficher de plus en plus d’informations. Par exemple, elle peut maintenant afficher le contenu des iovec (par exemple pour les fonctions readv ou writev), ainsi que les objets manipulĂ©s par wait_for_object et event_queue.

Un exemple de sortie de strace (traçant l’ouverture d’un fichier et le chargement d’une bibliothĂšque partagĂ©e) avant ces changements:

open(0x5, "plaintext", 0x2042, 0x0) = 0x8000000f () (49 us)
map_file("libicuuc.so.66 mmap area", 0x7f04c2675228, 0x6, 0x1ababd0, 0x1, 0x0, true, 0x3, 0x0) = 0x329a0 () (108 us)

et aprĂšs :

open(0x5, "plaintext", O_RDWR|O_NOTRAVERSE|O_CLOEXEC, 0x0) = 0x8000000f Operation not allowed (57 us)
map_file("libicuuc.so.66 mmap area", [0x0], B_RANDOMIZED_ANY_ADDRESS, 0x1ababd0, B_READ_AREA, 0x0, true, 0x3, 0x0) = 0x73e8 ([0x6392223000]) (135 us)

whence

La commande whence permettait de trouver dans le PATH un exĂ©cutable Ă  partir de son nom. Elle Ă©tait implĂ©mentĂ©e sous forme d’une fonction bash dans le fichier profile par dĂ©faut. Cependant, cette implĂ©mentation posait problĂšme pour charger le fichier profile avec d’autres shells, elle a donc Ă©tĂ© supprimĂ©e. La commande which peut ĂȘtre utilisĂ©e Ă  la place, puisqu’elle remplit un rĂŽle Ă©quivalent.

Serveurs

Les serveurs sont l’équivalent des daemons pour UNIX ou des services sous Windows : il s’agit d’applications lancĂ©es par le systĂšme pour rendre diffĂ©rents services et coordonner l’ensemble des applications.

app_server

app_server est le serveur graphique de Haiku, Ă©quivalent de X ou de Wayland. Il se distingue par un rendu graphique fait principalement cĂŽtĂ© serveur (pour les applications natives), ce qui permet de l’utiliser de façon fluide Ă  travers une connexion rĂ©seau.

Bien que ce soit le serveur graphique, et qu’il ait reçu plusieurs amĂ©liorations importantes, les diffĂ©rences sont subtiles. Elles sont toutefois importantes pour proposer un systĂšme qui semble rĂ©actif et confortable Ă  utiliser.

Un premier changement est une rĂ©architecture du code qui traite le rafraĂźchissement de l’écran. Ce rafraĂźchissement se fait en gĂ©nĂ©ral en plusieurs Ă©tapes, par exemple, si on dĂ©place une fenĂȘtre :

  • Le contenu de la fenĂȘtre dĂ©placĂ©e peut ĂȘtre directement recopiĂ© de l’ancienne position vers la nouvelle,
  • La zone oĂč se trouvait la fenĂȘtre auparavant doit ĂȘtre re-remplie avec ce qui se trouvait en dessous de la fenĂȘtre dĂ©placĂ©e. Cela peut ĂȘtre plusieurs morceaux de fenĂȘtres d’autres applications, qui vont devoir chacune rĂ©-afficher une partie de cette zone.

Le problĂšme Ă©tant que certaines applications peuvent mettre un peu de temps Ă  rĂ©pondre Ă  cette demande de rĂ©-affichage (par exemple parce qu’elles sont occupĂ©es ailleurs, ou alors parce que la zone Ă  redessiner est relativement complexe).

DiffĂ©rentes stratĂ©gies peuvent ĂȘtre mises en place dans ce cas : laisser Ă  l’écran le contenu obsolĂšte, ou remplir la zone en blanc en attendant que les donnĂ©es deviennent disponibles, par exemple. Ou encore, tout simplement ne rien mettre Ă  jour du tout tant que tout l’écran n’est pas prĂȘt Ă  ĂȘtre affichĂ©. Il faut faire un compromis entre la rĂ©activitĂ© (dĂ©placer la fenĂȘtre tout de suite), la fluiditĂ© (Ă©viter les clignotements de zones blanches) et la prĂ©cision (affichage d’information cohĂ©rente et Ă  jour).

Plusieurs modifications ont permis d’obtenir un meilleur compromis.

Dans un autre domaine, la police de caractĂšres par dĂ©faut « Noto Sans Display » a Ă©tĂ© remplacĂ©e par « Noto Sans », ce qui donne un affichage du texte lĂ©gĂšrement diffĂ©rent. La police « display » avait Ă©tĂ© choisie suite Ă  une mauvaise comprĂ©hension de la signification de ce mot en typographie : il signifie que c’est une police de caractĂšres Ă  utiliser pour des gros titres et autres textes courts. Il ne signifie pas que c’est une police Ă  utiliser sur un Ă©cran d’ordinateur. De toutes façons la police Noto Display n’est plus maintenue par Google et a disparu des derniĂšres versions du jeu de polices Noto.

Toujours dans le domaine des polices de caractĂšres, app_server sait maintenant charger les fichiers « variable fonts ». Ces fichiers contiennent plusieurs polices de caractĂšres dĂ©finies Ă  partir de glyphes de base, et d’algorithmes de transformation et de dĂ©formation (pour rendre une police plus ou moins grasse, plus ou moins italique
). Pour l’instant, app_server sait charger les valeurs de ces paramĂštres qui sont prĂ©configurĂ©es dans le fichier. Cela permet de rĂ©duire la place utilisĂ©e par les polices de caractĂšres sur le media d’installation de Haiku (c’est l’un des plus gros consommateurs d’espace disque, qui nous empĂȘche de faire tenir une version complĂšte de Haiku sur un CD de dĂ©monstration par exemple).

Plus tard, il sera Ă©galement possible de configurer plus finement ces paramĂštres pour gĂ©nĂ©rer des variantes intermĂ©diaires des polices de caractĂšres, ainsi que d’exploiter certaines polices qui offrent des paramĂštres configurables supplĂ©mentaires.

input_server

L’input_server se charge de lire les donnĂ©es venant des pĂ©riphĂ©riques d’entrĂ©e (clavier et souris) et de les convertir en Ă©vĂšnements distribuĂ©s aux applications. Il est extensible par des add-ons qui peuvent gĂ©nĂ©rer ou filtrer des Ă©vĂšnements, ce qui peut ĂȘtre utilisĂ© pour de l’accessibilitĂ© (Ă©muler une souris Ă  partir de touches du clavier), de l’automatisation (envoi de commandes prĂ©-enregistrĂ©es), du confort d’utilisation (bloquer le touchpad d’un ordinateur portable lorsque le clavier est en cours d’utilisation) et bien d’autres choses.

L’input_server a reçu des corrections de problĂšmes sur la gestion des rĂ©glages de souris, permettant en particulier d’utiliser des rĂ©glages diffĂ©rents pour plusieurs pĂ©riphĂ©riques (souris, touchpad), et que ceux-ci soient bien enregistrĂ©s.

registrar

Le serveur registrar suit les applications en cours de fonctionnement, et leur permet de communiquer entre elles au travers de l’envoi de messages. Il assure Ă©galement le suivi de la base de donnĂ©es des types MIME et des associations de types de fichiers avec les applications correspondantes.

L’implĂ©mentation de BMessageRunner, qui permet d’envoyer des messages pĂ©riodiques (par exemple pour faire clignoter le curseur des zones de texte Ă  la bonne vitesse), autorise maintenant des intervalles de rĂ©pĂ©tition en dessous de 50 millisecondes. Cela permet d’utiliser ce systĂšme pour des animations fluides de l’interface graphique, par exemple.

D’autre part, la liste des applications et documents rĂ©cemment lancĂ©s est maintenant limitĂ©e Ă  100 entrĂ©es. Cela Ă©vite un fichier qui grossit indĂ©finiment et finit par contenir surtout des vieilles informations sans intĂ©rĂȘt.

Kits

Le systĂšme Haiku fournit les mĂȘmes APIs que BeOS. Elles couvrent les usages basiques d’une application, et sont dĂ©coupĂ©es (dans la documentation de BeOS et de Haiku, au moins) en « kits » qui prennent chacun en charge une partie spĂ©cifique (interface graphique, multimĂ©dia, jeux vidĂ©os, accĂšs au matĂ©riel, etc).

Interface

L’interface kit est la partie de la bibliothùque standard qui se charge des interfaces graphiques.

 BColumnListView

BColumnListView est un ajout de Haiku par rapport Ă  BeOS. Il s’agit d’un Ă©lĂ©ment d’interface permettant de prĂ©senter une liste avec plusieurs colonnes, de trier les lignes selon le contenu de ces colonnes, et aussi d’avoir des items hiĂ©rarchisĂ©s avec la possibilitĂ© de plier et dĂ©plier une partie de l’arborescence.

Cette classe remplace avantageusement BListView et surtout BColumnListView, les classes historiques de BeOS, qui sont beaucoup plus limitées.

Un certain nombre de type de colonnes prĂ©dĂ©finis sont Ă©galement disponibles, ce qui facilite la construction d’interfaces prĂ©sentant les donnĂ©es de diffĂ©rentes applications avec le mĂȘme formatage.

La classe BColumnListView elle-mĂȘme n’a pas changĂ©. Par contre, les colonnes de type « taille » (pour afficher une taille en Kio, Mio, Gio
) et « date » utilisent la langue choisie dans les prĂ©fĂ©rences systĂšme au lieu d’un format anglais par dĂ©faut.

BTextView

BTextView est une classe permettant d’afficher une zone de texte Ă©ditable. Elle implĂ©mente les fonctionnalitĂ©s de base (curseur, sĂ©lection, retour Ă  la ligne automatique) ainsi que quelques possibilitĂ©s de mise en forme (couleurs, polices de caractĂšres).

BTextView peut Ă©galement ĂȘtre utilisĂ©e pour des zones de textes non Ă©ditables, souvent plus courtes. Cela permet de rĂ©utiliser une partie des algorithmes de mise en page et de formatage du texte dans diffĂ©rents contextes. Dans le cadre de l’utilisation du « layout system », une vue doit pouvoir indiquer sa taille minimale, maximale et optimale. Le « layout system » va ensuite calculer la meilleure disposition de fenĂȘtre possible pour satisfaire ces contraintes.

Le cas des zones de texte est particulier, car la hauteur optimale dĂ©pend du nombre de lignes de texte, qui lui-mĂȘme peut ĂȘtre plus ou moins grand si la largeur de la vue oblige Ă  ajouter des retours Ă  la ligne. Le « layout kit » prend en compte ce cas particulier, mais les algorithmes ne sont pas encore tout Ă  fait au point et peuvent conduire Ă  des rĂ©sultats inattendus dans certains cas. Un de ces cas particuliers sur les zones de texte non Ă©ditables a Ă©tĂ© corrigĂ©.

BMenu

La classe BMenu permet d’afficher un menu. Elle est utilisĂ©e de plusieurs façons, puisqu’on trouve des menus dans des barres de menu, dans des contrĂŽles de type « popup », ou encore en faisant un clic droit sur certains Ă©lĂ©ments de l’interface.

Les menus sont Ă©galement particuliers parce qu’ils peuvent d’étendre en dehors de la fenĂȘtre dont ils sont originaires. Ils sont donc implĂ©mentĂ©s sous forme de fenĂȘtres indĂ©pendantes. Mais cela pose un autre problĂšme : dans Haiku, chaque fenĂȘtre exĂ©cute son propre thread et sa propre boucle d’évĂšnements. Si on navigue dans un grand nombre de menus et de sous-menus, cela peut causer quelques problĂšmes de synchronisation et de performances.

Le code contient Ă©galement un grand nombre de cas particuliers pour, par exemple, aligner les raccourcis claviers et les flĂšches indiquant la prĂ©sence de sous-menus ente les diffĂ©rents items d’un menu, ou encore dĂ©tecter si un dĂ©placement de souris a pour but de sĂ©lectionner un autre menu (en dessous ou au-dessus de celui actif), ou bien plutĂŽt de naviguer vers un sous-menu.

Les nouveautés suivantes sont apparues cette année:

  • Correction de problĂšmes de race condition lors de l’ajout d’items dans un menu pendant qu’il est affichĂ© Ă  l’écran. Ce problĂšme se manifestait par exemple dans les menus affichant la liste des rĂ©seaux Wifi, qui sont mis Ă  jour en temps rĂ©el.
  • Finalisation de l’implĂ©mentation de la navigation au clavier (avec les flĂšches directionnelles) dans les menus.
  • Affichage des symboles graphiques UNICODE pour « backspace » (⌫) et « delete » (〈) si ces touches sont utilisĂ©es comme raccourcis clavier pour un item de menu.
  • Utilisation d’un algorithme de tri stable pour la fonction SortItems. Ce type d’algorithme prĂ©serve l’ordre relatif des items qui sont Ă©gaux d’aprĂšs la fonction de comparaison. Ce n’est pas le cas de certains algorithmes de tri classiques, notamment le quicksort. La consĂ©quence Ă©tait que trier un menu dĂ©jĂ  triĂ© pouvait changer l'ordre des items. C’était visible encore une fois sur le menu listant les rĂ©seaux Wifi, qui est triĂ© par puissance du signal reçu.

 BSpinner

BSpinner est un contrĂŽle permettant de choisir une valeur numĂ©rique, soit Ă  l’aide de boutons +/- pour modifier la valeur par incrĂ©ments, soit en entrant directement la valeur dans une zone de texte.

Il s’agit d’une extension de Haiku par rapport Ă  BeOS qui ne proposait pas cette fonctionnalitĂ©.

Cette classe est encore en cours de développement. Elle a reçu des améliorations pour désactiver correctement les boutons +/- lorsque la valeur atteint le minimum ou le maximum autorisé, et aussi une correction sur le message de notification envoyé lors des changements de valeurs du spinner, qui ne contenaient pas la bonne valeur.

rgb_color

La structure rgb_color permet de reprĂ©senter une couleur par la valeur de ses composantes rouge, vert, bleu (comme son nom l’indique) et alpha (comme son nom ne l’indique pas). Elle fournit Ă©galement un certain nombre de fonctions pour mĂ©langer des couleurs, les Ă©claircir ou les assombrir.

La mĂ©thode Brightness() dans la classe rgb_color implĂ©mentante maintenant l’algorithme perceptual brightness documentĂ© par Darel Rex Finley, qui donne des meilleurs rĂ©sultats que l’algorithme utilisĂ© prĂ©cĂ©demment (qui Ă©tait celui de la luminositĂ© dans l’espace de couleurs Y'IQ. La fonction perceptual_brightness devenue redondante est supprimĂ©e.

Cette mĂ©thode permet en particulier de dĂ©terminer si une couleur est « sombre » ou « claire », et ainsi de dĂ©cider si du texte affichĂ© par-dessus doit ĂȘtre blanc ou noir (comme dĂ©montrĂ© ici par exemple).

Locale

Le locale kit se charge de tous les aspects liés à la localisation : traductions des applications, formatage des messages en utilisant les rÚgles de pluralisation de chaque langue, formatage de dates, de nombres avec et sans unités, de pourcentages, nom des fuseaux horaires


Il utilise ICU pour implĂ©menter la plupart de ces fonctionnalitĂ©s, mais fournit une surcouche avec une API s’intĂ©grant mieux avec les autres kits.

La principale Ă©volution cette annĂ©e est l’implĂ©mentation de BNumberFormat, qui permet de formater des nombres. Elle permet de choisir une prĂ©cision (nombre de dĂ©cimales - pour les langues qui utilisent un systĂšme dĂ©cimal), d’afficher ou non des sĂ©parateurs de groupes (de milliers en français, mais par exemple en Inde la sĂ©paration se fait traditionnellement par multiples de 10 000).

Media

Le media kit se charge de tous les aspects multimedia.

Il se compose de deux parties. D’une part, un systĂšme de gestion de flux mĂ©dia temps rĂ©el, permettant de transfĂ©rer des donnĂ©es multimĂ©dia (son ou flux vidĂ©o par exemple) entre diffĂ©rentes applications qui vont les manipuler, le tout avec un certain contrĂŽle du temps de traitement ajoutĂ© par chaque opĂ©ration, pour tenter de minimiser la latence tout en Ă©vitant les vidages de tampons qui produiraient une interruption dans le flux. D’autre part, des classes permettant d’encoder et de dĂ©coder des fichiers mĂ©dia et d’en extraire des flux de donnĂ©es (encodĂ©es ou dĂ©codĂ©es).

C’est surtout cette deuxiĂšme partie qui a reçu quelques Ă©volutions. La version de ffmpeg utilisĂ©e pour le dĂ©codage de presque tous les formats audio et video est maintenant la derniĂšre version ffmpeg 6. Quelques autres problĂšmes (erreurs d’arrondis, gestion des tampons partiels en fin de fichier) ont Ă©galement Ă©tĂ© corrigĂ©s, ce qui permet de faire fonctionner Ă  nouveau le jeu BePac Deluxe qui est extrĂȘmement intolĂ©rant au moindre Ă©cart de comportement par rapport Ă  l’implĂ©mentation du Media Kit dans BeOS.

Support

Le support kit contient un ensemble de classes basiques mais indispensables : gestion des chaßnes de caractÚres, des tampons en mémoire, etc. Il fournit les briques de bases utilisées par les autres kits.

BDataIO

BDataIO est une classe abstraite avec des fonctions de lecture et d’écriture. Plusieurs autres classes sont des instances de BDataIO, par exemple BFile (reprĂ©sentant un fichier), mais aussi BMemoryIO (permettant d’accĂ©der Ă  une zone mĂ©moire).

Plusieurs autres classes acceptent BDataIO (ou sa sous-classe BPositionIO, qui ajoute la possibilitĂ© de se dĂ©placer Ă  une position donnĂ©e dans le flux) comme entrĂ©e ou comme sortie. Il est donc facilement possible de rĂ©aliser les mĂȘmes opĂ©rations sur un fichier, une zone de donnĂ©es en mĂ©moire, un socket rĂ©seau, ou tout autre objet susceptible de fournir une interface similaire.

BDataIO elle-mĂȘme n’a pas Ă©voluĂ©, mais deux de ses implĂ©mentations, BBufferedDataIO et BAdapterIO, ont Ă©tĂ© amĂ©liorĂ©es. Ces deux classes permettent de construire un objet BDataIO Ă  partir d’un autre, en ajoutant un cache en mĂ©moire pour accĂ©lĂ©rer les opĂ©rations ou encore pour rendre compatible avec BPositionIO un objet qui ne l’est pas.

Ces classes sont en particulier utilisĂ©es par l’application StreamRadio, qui implĂ©mente la lecture de podcasts en connectant directement le rĂ©sultat d’une requĂȘte HTTP (effectuĂ©e grace au network kit) dans un dĂ©codeur audio (via la classe BMediaFile du media kit). La mise en tampon permet de revenir en arriĂšre dans la lecture d’un Ă©pisode, de tĂ©lĂ©charger en avance les donnĂ©es qui vont ĂȘtre lues, et d’éviter de conserver inutilement en mĂ©moire les donnĂ©es qui sont dĂ©jĂ  lues par l’application.

BibliothĂšques C

Les « kits » mentionnĂ©s ci-dessus sont l’API en C++ utilisĂ©e par les applications Haiku.

Il existe aussi des APIs en C, en grande partie implémentant la bibliothÚque C standard et les fonctions décrites dans la spécification POSIX.

Libroot

Libroot implĂ©mente la bibliothĂšque standard C. Elle regroupe entre autres la libc, la libm, et la libpthread, qui sont parfois implĂ©mentĂ©es comme 3 bibliothĂšques diffĂ©rentes pour d’autres systĂšmes. Les Ă©volutions consistent Ă  complĂ©ter l’implĂ©mentation de la spĂ©cification POSIX, et Ă  suivre les Ă©volutions de cette derniĂšre ainsi que des nouvelles versions du langage C. On trouve Ă©galement des corrections de bugs dĂ©couverts en essayant de faire fonctionner de plus en plus d’applications sur Haiku, ce qui permet de mettre en Ă©vidence des diffĂ©rences de comportement avec d’autres systĂšmes.

  • Ajout de getentropy pour initialiser les gĂ©nĂ©rateurs de nombres alĂ©atoires
  • Correction de problĂšmes de locks au niveau de l’allocateur mĂ©moire lors d’un fork
  • Plusieurs corrections sur l’implĂ©mentation de locale_t, remplacement de code Ă©crit pour Haiku ou provenant de FreeBSD par une implĂ©mentation simplifiĂ©e mais suffisante, provenant de la bibliothĂšque C musl.
  • Ajout de static_assert en C11
  • Correction d’un crash lors de l’utilisation de certaines fonctions XSI
  • Ajout de stpncpy
  • La fonction open utilisĂ©e sur un lien symbolique pointant vers un fichier non existant peut maintenant crĂ©er le fichier cible.
  • Il est possible d’utiliser mmap sur un fichier plus grand que la mĂ©moire disponible sans avoir besoin de spĂ©cifier le flag MAP_NORESERVE
  • Utiliser rename pour renommer un fichier vers lui-mĂȘme ne retourne plus d’erreur (conformĂ©ment Ă  la spĂ©cification POSIX).
  • Ajout de pthread_sigqueue

Libnetwork

La libnetwork implĂ©mente les APIs nĂ©cessaire pour se connecter au rĂ©seau (sockets, rĂ©solution DNS
). Elle est sĂ©parĂ©e de la bibliothĂšque C pour des raisons historiques : l’implĂ©mentation de TCP/IP pour BeOS avait Ă©tĂ© rĂ©alisĂ©e entiĂšrement en espace utilisateur (le noyau n’offrant qu’une interface pour envoyer et recevoir des paquets ethernet sur la carte rĂ©seau). Cela a posĂ© des problĂšmes de compatibilitĂ© avec d’autres systĂšmes, et des problĂšmes de performance. Haiku est donc compatible avec la version "BONE" de BeOS, qui implĂ©mente la pile rĂ©seau dans le noyau.

  • Mise Ă  jour du rĂ©solveur DNS Ă  partir du code de NetBSD 9.3. PrĂ©cĂ©dement le code utilisĂ© Ă©tait celui du projet netresolv de NetBSD, mais ce projet n’a pas connu de nouvelles publications et le code est Ă  nouveau maintenu directement dans NetBSD sans publication sĂ©parĂ©e.
  • Correction d’un crash lors de l’utilisation de multicast IPv4

LibBSD

La libbsd implĂ©mente plusieurs extensions fournies par la libc de certains systĂšmes BSD. Elle est sĂ©parĂ©e de la bibliothĂšque C principale pour limiter les problĂšmes de compatibilitĂ©: certaines applications prĂ©fĂšrent fournir leur propre version de ces fonctions, ou d’autres fonctions avec le mĂȘme nom mais un comportement diffĂ©rent. Elles peuvent alors s’isoler en n’utilisant pas la libbsd pour Ă©viter toute interfĂ©rence.

LibGNU

De façon similaire à la libbsd, la libgnu fournit des fonctions qui sont disponibles dans la glibc (la bibliothùque C du projet GNU) mais ne font pas partie d’un standard (C ou POSIX).

  • Ajout de sched_getcpu pour savoir sur quel cƓur de CPU le thread appelant est en train de s’exĂ©cuter.
  • Ajout de pthread_timedjoin_np, pour attendre la fin de l’exĂ©cution d’un thread (comme pthread_join mais avec un timeout.

Commentaires : voir le flux Atom ouvrir dans le navigateur

Calligra : laquelle choisir ? notre comparatif secret (il sera aussi question de formats)

PlutĂŽt qu’un comparatif entre Calligra, une prĂ©sentation rapide de la suite bureautique de KDE s’impose. Une suite qui vient de passer en version 4 aprĂšs quelque chose comme quatre ans de stase. Comparer la petite suite Calligra Ă  LibreOffice serait assez injuste. NĂ©anmoins cette prĂ©sentation des quatre logiciels qui la forment ne peut pas faire complĂštement l’impasse dessus. Et, notamment, mais pas uniquement, Ă  cause des formats de fichier et de leur compatibilitĂ© entre les deux suites bureautiques libres.

Ne faites pas attention au titre qui a été plus ou moins suggéré à titre de plaisanterie dans ce commentaire.

Le panneau de démarrage de Calligra

Sommaire

Calligra, vingt-six ans déjà

Les dĂ©buts de Calligra remontent, d’aprĂšs « l’À propos de Calligra Â» Ă  1998. Au dĂ©part, sous le nom de KOffice. Elle n’adoptera ce nom de Calligra suite qu’en 2010. La derniĂšre version de Koffice, numĂ©ro 2.3.3 est sortie en 2011.

En 2020, Calligra sort une version 3.2.1. Puis, plus rien jusqu’au 27 aoĂ»t 2024 oĂč un dĂ©veloppeur KDE, Web et QML, Carl Schwan, annonce la sortie de la version 4.0 (en). Pour cette nouvelle version, il a essentiellement d’une part complĂštement portĂ© l’Api de QT6 Ă  KF6, d’autre part revu l’interface utilisateur.

Dans sa prĂ©sentation de la suite, KDE indique que Calligra s'appuie sur KDE, une architecture d’applications puissante. On verra plus tard que ce n’est pas sans consĂ©quence.

Les formats de fichier natifs de Calligra sont les formats ODF. Un choix que KDE explique dans la vue d’ensemble des fonctions de Calligra :

Il est d’une importance majeure pour toute suite bureautique d’adhĂ©rer Ă  des standards Ă©tablis. Surtout au niveau du format de fichier pour permettre l’échange de documents avec d’autres suites bureautiques de maniĂšre transparente. Cela Ă©vite Ă©galement les formats propriĂ©taires, ce qui est particuliĂšrement important pour les entreprises et pour les particuliers.

Le traitement de texte Kword aura d’ailleurs Ă©tĂ© le premier logiciel de traitement de texte Ă  prendre en charge le format ODF qui est sorti en 2005.

Quelques mots sur la suite

Calligra comporte quatre logiciels :

  • Karbon, l’application de dessin vectoriel,
  • Calligra Sheets, le tableur,
  • Calligra Stage, le logiciel de prĂ©sentation,
  • Calligra Words, le traitement de texte.

Il y a, en outre, un panneau de dĂ©marrage, Calligra, qui figure en illustration de la dĂ©pĂȘche. En cliquant sur une des icĂŽnes, on ouvre l’application concernĂ©e. Chaque application propose de choisir entre un document rĂ©cent, un document personnalisĂ© ou un modĂšle ou type de modĂšle.

Les quatre applications de la suite bureautique Calligra.

Ensuite, tous les logiciels de la suite ont la mĂȘme logique : une barre de menu et (optionnellement) des barres d’outils en haut, et sur les cĂŽtĂ©s, Ă  droite ou Ă  gauche selon la configuration, une barre latĂ©rale qui sert quasiment pour tout.

La configuration de l’emplacement de la barre latĂ©rale se fait par un clic droit dessus. Il est possible d’indiquer par la mĂȘme occasion si on veut que les icĂŽnes des panneaux latĂ©raux soient assorties de texte ou non. Les choix que j’ai fait dans les captures d’écran sont diffĂ©rents de ceux de la note de blog de Carl Schwan.

Barre latérale
Configuration de l’emplacement de la barre latĂ©rale.

Par dĂ©faut, les barres d’outils, qui, au demeurant, comportent trĂšs peu d’élĂ©ments, ne sont pas affichĂ©es. Il y en a deux : Éditer qui affiche les boutons DĂ©faire et Refaire (et c’est tout) et Fichier qui permet d’afficher ou non les panneaux. Dans les captures d’écran de cette dĂ©pĂȘche, elles sont toutes deux affichĂ©es. Pour les avoir Ă  l’écran : ParamĂštres > Barres d’outils affichĂ©es.

Barres d’outils affichĂ©es
C’est aussi Ă  ce niveau qu’on configure la vĂ©rification orthographique et la correction automatique.

On peut, évidemment, créer des modÚles (formats OTF) avec chacune des quatre applications de la suite bureautique et exporter le fichier au format PDF. Les polices des fichiers générés en PDF sont complÚtement intégrées, ce qui en fait des documents assez lourds.

Karbon, dessin vectoriel

Si le format natif de Karbon est l’ODG, il peut enregistrer aussi aux formats WMF, JPEG, PNG et SVG. C’est un logiciel assez facile à utiliser, moyennant un temps d’apprentissage, et dont l’interface peut rappeler celle de Draw avec sa barre d’outils de dessin à gauche.

Karbon

Karbon ouvre trĂšs bien les fichiers SVG simples, mais, dĂšs qu’il y a des dĂ©gradĂ©s, des motifs ou des images matricielles incorporĂ©es, le rĂ©sultat est moins bon.

Karbon et les images SVG
À gauche la version originale dans Inkscape, Ă  droite la version ouverte dans Karbon. Le manchot est plus petit, l’effet de dĂ©gradĂ© de ses lunettes a disparu et le fond de l’Ɠuf est complĂštement pixelisĂ©.

Calligra Sheets : tableur de son mĂ©tier

Le tableur de Calligra est le seul Ă  proposer plusieurs catĂ©gories de modĂšles, tous en anglais. Il est assez peu traduit par rapport Ă  ses collĂšgues. Ainsi, dans Calligra Words, on a un « Gestionnaire de styles, quand, dans Sheets, c’est un « Style Manager Â». Il fonctionne comme n’importe quel autre tableur. La modification d’un diagramme dans Calligra Sheets est trĂšs facile, mis Ă  part le fait qu’il ne semble pas qu’on puisse en changer les couleurs.

L’interface de Calligra Sheets

Outre l’ODS, il peut enregistrer aux formats : Kspread (ancien format de la suite Koffice), CSV, LibreOffice Calc spreadsheet (qui est aussi de l’ODS), feuille de calcul Gnumeric, Html et TeX.

Calligra Stage, présentation

Le logiciel de prĂ©sentation Calligra Stage est le seul Ă  proposer plusieurs modĂšles, certains avec une, d’autres avec deux pages maĂźtre dont un sympathique modĂšle avec un manchot : « Pingouin curieux Â». Il peut ĂȘtre dĂ©concertant de prime abord quand on part d’un « Ă©cran vide Â» ou « 16:10 Â» parce que ce qui apparaĂźt c’est un espace complĂštement vide sans zone prĂ©-configurĂ©e. Mais, si on clique sur la premiĂšre icĂŽne du panneau latĂ©ral, on accĂšde Ă  plusieurs « Styles Â» de diapositives qui ont ces zones.

Manchot curieux

Calligra Stage n’enregistre qu’au format ODP.

Calligra Words, traitement de texte

Calligra Words ne propose que quatre modĂšles dont un trĂšs dĂ©suet modĂšle de fax et un modĂšle de « lettre professionnelle Â» qui n’est qu’une page vide avec des grandes marges. Il est possible, en thĂ©orie, d’ajouter des entĂȘtes et des pieds de page avec des champs de type numĂ©ro de page ou titre du document, troisiĂšme icĂŽne du panneau latĂ©ral en partant du haut. Mais il y a un bug d’affichage car rien n’apparaĂźt, alors qu’on les voit quand on ouvre le fichier dans Writer. On peut insĂ©rer des notes sans possibilitĂ© de naviguer de l’appel de note vers la note et vice-versa. Au mĂȘme endroit, il est possible d’ajouter simplement une citation ou une bibliographie, mais pas de table des matiĂšres ni d’index.

L’espace de travail de Calligra

Calligra Words enregistre aussi aux formats : document Word 2007, Electronic book document, Plain texte document, livre numĂ©rique Mobipocket, Text Plain Wiki Format et HTML. C’est, Ă  mon avis, de tous les logiciels de la suite, celui qui a le plus mal vieilli.

Limites et (in)compatibilités

Il ne s’agit pas de relever les fonctionnalitĂ©s, souvent gourmandes en ressources de dĂ©veloppement, manquantes par rapport Ă  d’autres suites bureautiques dĂ©veloppĂ©es par des Ă©quipes nettement plus Ă©toffĂ©es.

Sans Plasma, ça fonctionne moins bien

La grosse limite de Calligra est le fait qu’elle est dĂ©veloppĂ©e pour bien s’intĂ©grer Ă  KDE. Ce qui aboutit Ă  ce qu’avec la version Flatpak et un environnement bureau qui n’est pas KDE (ici XFCE), Calligra Words ne peut pas faire de vĂ©rification orthographique dans une autre langue que l’anglais. Alors que la mĂȘme version fonctionne bien sur ce plan dans un environnement de bureau Plasma. On peut imaginer que cela fonctionnerait mieux si la version Ă©tait empaquetĂ©e pour la distribution.

Calligra ne trouve pas non plus les polices ajoutĂ©es dans le dossier .fonts dans un cas alors qu’il les trouve quand la session de bureau est Plasma. Un autre dĂ©faut : on ne peut pas ajouter de caractĂšre « spĂ©cial Â» en utilisant les combinaisons de touches Ctrl + Maj + U ou Alt + X. Calligra Words ne permet pas, par exemple, d’avoir des chevrons typographiques : « Â», mĂȘme avec Plasma.

Formats et compatibilité

Petit rappel historique du format ODF. La version 1.0 du format sort en mai 2005, suivie, en fĂ©vrier 2007, de la version 1.1. Quatre ans plus tard, en mars 2011, la version 1.2 pointera le bout de ses octets, puis, en juin 2021, le consortium OASIS qui gĂšre la norme, accepte la version 1.3 adoptĂ©e par LibreOffice avec les versions 7. À l’heure actuelle, la version 1.4 est en cours de travail. LibreOffice est en train de travailler Ă  la prise en charge de cette version avec la premiĂšre Ă©tape, la budgĂ©tisation (en).

Le format ODF de Calligra Suite est donc, compte tenu du fait que le travail sur cette version n’a pas Ă©tĂ© axĂ© sur la prise en charge de l’ODF, probablement 1.2 ou 1.1. Cela a des consĂ©quences si on veut Ă©changer des fichiers entre, notamment, les suites LibreOffice et Calligra ou, encore, utiliser des modĂšles rĂ©cupĂ©rĂ©s sur le site des extensions et modĂšles (en) de LibreOffice.

Quelques-uns des problĂšmes que j’ai pu relever. Le plus ennuyeux, c’est quand on perd l’information dĂ©finitivement dans Calligra.

Avec Karbon, si on veut ouvrir un fichier ODG gĂ©nĂ©rĂ© dans Draw, avec des formes converties en « Corps de rĂ©volution 3D Â», en 3D ou avec un dĂ©gradĂ© radial, les deux premiĂšres disparaissent dĂ©finitivement. Et, quand on veut ouvrir le fichier, qu’on aura enregistrĂ© dans Karbon, le dĂ©gradĂ© de la seule forme conservĂ© n’est plus pareil. Ce dernier fait est, je pense, liĂ© Ă  la gestion des couleurs et aux palettes disponibles dans l’une et l’autre suite.

Calligra Sheets ne comprend pas bien les plages et expressions nommĂ©es, une fonctionnalitĂ© que possĂšde le logiciel. C’est un problĂšme que j’avais dĂ©jĂ  constatĂ© dans OpenOffice il y a un paquet d’annĂ©es. En consĂ©quence, il affiche une erreur #VALEUR! dans les cellules. Si on rĂ©-ouvre le fichier sauvegardĂ© dans LibreOffice, c’est fichu. Si mes souvenirs sont exacts, Ă  l’époque quand j’avais signalĂ© ce problĂšme de LibreOffice vers OpenOffice, il m’avait Ă©tĂ© rĂ©pondu que c’est probablement dĂ» Ă  une question de version d’ODF.

Sans surprise, les dĂ©gradĂ©s entre les logiciels de prĂ©sentation des deux suites bureautiques libres, Calligra Stage et Impress, sont interprĂ©tĂ©s diffĂ©remment. Sans surprise aussi, Calligra Stage affiche plus ou moins bizarrement les formes qu’il n’a pas Ă©tĂ© programmĂ© pour comprendre. Mais on peut les retrouver correctement dessinĂ©es Ă  l’ouverture dans Impress. Vous pouvez faire un test, si vous voulez, avec le modĂšle Tons pastels. En revanche, les dimensions, comme pour le cas du manchot dans Karbon, ne sont pas toujours respectĂ©es. Et une prĂ©sentation crĂ©Ă©e dans Stage et ouverte dans Impress peut assez considĂ©rablement varier d’allure, notamment la taille et la couleur des caractĂšres.

Deux versions d’une mĂȘme prĂ©sentation
En haut la version originale crĂ©Ă©e avec Stage. En bas, ouverte dans Impress : l’arriĂšre-plan dĂ©gradĂ© de bleus, s’est transformĂ© en dĂ©gradĂ©s de noir au blanc, et le texte a changĂ© d’allure.

Quant Ă  Calligra Words, il regroupe toutes les images ancrĂ©es au paragraphe au dĂ©but du document et ne garde pas forcĂ©ment la mise en page. Pire, s’il y a des variables dans le document, elles disparaissent dĂ©finitivement corps et Ăąmes, il y a donc une sĂ©rieuse perte d’information. Sans nĂ©gliger ce bug de non affichage des champs compris pourtant par Calligra Words.

Suggestion et demande

Il y a quelques annĂ©es, je trouvais Calligra vraiment sympathique. Quelques annĂ©es aprĂšs, la suite est toujours sympathique, mais, quatre ans sans maintenance ni Ă©volution dans un secteur oĂč ça bouge, ça se fait sentir.

Utiliser ou pas Calligra ? À mon avis (Ă  moi, personnellement), peut-ĂȘtre pas si on n’a pas Plasma comme environnement de bureau. SĂ»rement pas, toujours Ă  mon avis Ă  moi, si on doit travailler des fichiers qui viennent d’ailleurs Ă  cause des histoires de format. Sauf si lesdits fichiers sont trĂšs simples. Si vous voulez utiliser des modĂšles du site des Extensions et modĂšles (en) de LibreOffice, j’aurais tendance Ă  vous suggĂ©rer de regarder la compatibilitĂ© des modĂšles avec les versions de LibreOffice, de ne pas aller plus loin que les versions 6 incluses et d’opter pour des modĂšles simples.

Cela dit, Karbon est vraiment un chouette logiciel. Si sa prise en mains vous est plus facile pour le dessin vectoriel que celle de Draw ou d’Inkscape, ne pas hĂ©siter. Et sa palette de couleurs est trĂšs bien.

D’ailleurs, puisqu’on parle de la palette de couleurs de Karbon, quelqu’un sait comment la rĂ©cupĂ©rer ? Je pourrais l’ajouter Ă  mon LibreOffice et Ă  mon Inkscape. Merci d’avance.

Et si vous voulez un tutoriel un peu plus complet sur la prise en mains de Calligra, c’est par là.

Commentaires : voir le flux Atom ouvrir dans le navigateur

Pour 100 briques t'as plus rien : le navigateur Ladybird reçoit un million de brouzoufs

AprĂšs les multiples dons de 100.000 $, le projet de navigateur web Ladybird reçoit 1 million de dollars du fondateur de Github.

Dans la foulĂ©e, le projet se dote d'une fondation de droit amĂ©ricain dont les statuts interdisent toute forme de dons ou de financements intĂ©ressĂ©s (cf. Google qui rĂ©munĂšre Mozilla pour ĂȘtre le moteur de recherche par dĂ©faut de Firefox). Et bien sĂ»r un site web tout neuf pour cĂ©lĂ©brer tout ça.

logo du navigateur Ladybird

Trois dĂ©veloppeurs sont engagĂ©s (en plus d'Andreas Kling) et trois autres arrivent (inutile de postuler, ça ne devrait pas augmenter : AndrĂ©as prĂ©fĂšre une petite Ă©quipe et veut toujours avoir les fonds pour un an et demi de salaires d'avance).

Une version alpha est prĂ©vue pour 2026. L'Ă©quipe utilise dĂ©jĂ  Ladybird pour travailler sur ses sites prĂ©fĂ©rĂ©s — Github, Discord, HackerNews
 avis aux amateurs ! À ceux qui pensent toujours que crĂ©er un nouveau moteur de rendu et un navigateur est un projet vouĂ© Ă  l'Ă©chec, remarquez de quelles pointures viennent les dons et les encouragements, le dernier en date Ă©tant Colin Hayhurst, crĂ©ateur du moteur de recherche Mojeek.

Commentaires : voir le flux Atom ouvrir dans le navigateur

TuxGuitar : c'est reparti pour un tour

TuxGuitar est un Ă©diteur / lecteur de tablatures multipistes, publiĂ© sous licence LGPL. Il s’adresse aux musiciens jouant de la guitare, de la basse, et plus gĂ©nĂ©ralement des instruments Ă  cordes frettĂ©es.

Logo du logiciel Tux Guitar

Ce logiciel a Ă©tĂ© dĂ©veloppĂ© et maintenu sur SourceForge de 2005 Ă  2022 par un dĂ©veloppeur argentin, Julian Gabriel Casadesus. Avec, comme pour beaucoup de logiciels libres, des pĂ©riodes de dĂ©veloppement plus ou moins actives au fil des annĂ©es. De maniĂšre assez soudaine, mi-2022, le dĂ©veloppeur a cessĂ© toute activitĂ©, et il n’a plus donnĂ© aucun signe de vie depuis. Le nom de domaine historique (en.com.ar) a cessĂ© d’ĂȘtre maintenu fin 2022. C’est bien dommage, une grande quantitĂ© d’information a Ă©tĂ© perdue.

Depuis des annĂ©es, TuxGuitar est une rĂ©fĂ©rence dans le monde du libre guitaristique. Alors pour les utilisateurs la question se pose : quel avenir pour TuxGuitar ?

En 2023, aprĂšs avoir tentĂ© de reprendre contact avec le crĂ©ateur de TuxGuitar sans succĂšs, quelques enthousiastes – dont je fais partie – ont relancĂ© une branche sur Github. Depuis, plusieurs nouvelles versions ont Ă©tĂ© publiĂ©es, la toute derniĂšre version 1.6.3 vient juste de sortir.

Adopter un logiciel libre orphelin peut s’avĂ©rer dĂ©licat : code source assez volumineux, aucune documentation, aucune base de test, commentaires trĂšs rares dans le code (et en espagnol). Et surtout, comment faire connaĂźtre ce projet ? C’est l’objet de cette dĂ©pĂȘche.

AprĂšs des dĂ©buts timides cette nouvelle initiative prend petit Ă  petit sa place, et une communautĂ© commence Ă  se recrĂ©er autour de ce nouveau dĂ©pĂŽt. Depuis fin avril cette nouvelle version est plus tĂ©lĂ©chargĂ©e que la version historique : TuxGuitar semble bel et bien reparti pour une seconde vie. À noter que wikipedia a suivi le mouvement et pointe maintenant sur ce nouveau dĂ©pĂŽt.

Copies d’écran de Tux Guitar en pleine action
TuxGuitar est disponible pour Linux (.tar.gz,.deb et.rpm), Windows, macOS, FreeBSD, et Android. Une version flatpak a Ă©tĂ© Ă©galement mise Ă  jour par la communautĂ©. CĂŽtĂ© distributions, je n’ai pas fait de recherche exhaustive, mais cette nouvelle mouture est disponible directement dans les dĂ©pĂŽts d’openSUSE. J’ai Ă©galement trouvĂ© un paquet pour ArchLinux, une spĂ©cification pour construire un paquet rpm pour Fedora, et des instructions pour Gentoo.

Certainement pas aussi complet que le logiciel commercial de rĂ©fĂ©rence, Guitar Pro, TuxGuitar reste une sĂ©rieuse alternative libre. Tout particuliĂšrement pour le monde Linux, que l’éditeur de Guitar Pro a officiellement abandonnĂ© depuis plusieurs annĂ©es.

Alors avis aux guitaristes, bassistes, ukulĂ©listes et autres instrumentistes Ă  cordes : n’hĂ©sitez pas Ă  y jeter un Ɠil, et Ă  faire circuler l’information !

Commentaires : voir le flux Atom ouvrir dans le navigateur

XL-Converter 1.0, billet d'humeur et plaidoyer

XL-Converter est un utilitaire graphique pour convertir vos images en formats utilisables sur Internet. Outre les classiques JPEG et PNG il y a donc AVIF, WEBP et JPEG-XL. L’outil se veut ergonomique avec un minimum d’options pratiques. Par exemple on peut indiquer une dimension ou un poids maximum pour les images. À mes yeux, l’intĂ©rĂȘt d’XL-Converter c’est surtout le format Jpeg. Pourquoi ? parce que ce format est loin d’ĂȘtre mort : tout en travaillant sur Jpeg-XL, les chercheurs suisses de Google ont dĂ©veloppĂ© un nouvel algorithme d’encodage du Jpeg classique, et cet algo est trĂšs performant.

Jpegli, le nouvel algo, tire son nom du jargon suisse, tout comme guetzli, butteraugli, etc. par la mĂȘme Ă©quipe. Il est inclus dans la version 0.10 de la libjxl, la bibliothĂšque de rĂ©fĂ©rence pour Jpeg-XL (c’est normal il en rĂ©utilise du code). Et par lĂ , il se retrouve l’encodeur Jpeg de XL-Converter.

Jpeg est un format de compression qui date des annĂ©es 80. C’est grĂące Ă  lui qu’on voit le web en couleur. On a souvent tentĂ© de le remplacer, il rĂ©siste. C’est normal, non content d’offrir un bon rapport qualitĂ©/poids, il y a belle lurette que nos puces dĂ©codent les images Jpeg en un Ă©clair. Jpeg est donc efficace et rapide, sa compression avec perte n’enlĂšve que des dĂ©tails invisibles Ă  nos yeux. Enfin il a des dĂ©fauts quand mĂȘme : pour gagner encore plus de poids, il gomme encore plus de dĂ©tails et nous laisse des artefacts bien visibles, qui ressemblent Ă  des saletĂ©s dans l’Ɠil, celles qu’on dĂ©couvre en regardant un mur blanc. En principe je ne vous apprends rien, vous ĂȘtes habituĂ©s Ă  optimiser le poids de vos images sur Internet et vous savez jouer du curseur pour obtenir le meilleur compromis pour la meilleure image Jpeg possible (© Voltaire).

Nos accĂšs Internet deviennent sans cesse plus rapides, la puissance et la Ram sur nos ordis augmentent de mĂȘme, les nuisances Ă©nergĂ©tiques itou. Ça m’importe. Et mĂȘme si les nuisances vous indiffĂšrent, vous vous ĂȘtes peut-ĂȘtre dĂ©jĂ  retrouvĂ© pris au piĂšge d’une zone blanche, ou bien sur une Ăźle surpeuplĂ©e de touristes en Ă©tĂ©, ou bien dans un pays lointain aux prises avec un vieil ordi malmenĂ© par les dĂ©bits inconstants et la lourdeur de votre site web prĂ©fĂ©rĂ©, bref dans ma peau. La situation est tout de mĂȘme assez commune pour qu'un des critĂšres majeurs de bon rĂ©fĂ©rencement des pages web sur Google soit le temps de chargement et d’affichage1.

Normalement vous savez qu’il y a plusieurs facteurs lĂ -dedans, matĂ©riels, logiciel et humain. Humain, voilĂ  ce qui nous intĂ©resse. C’est l’humain qui fait l’effort de soigner son code, d’utiliser un format qui dĂ©compresse vite, de redimensionner ses images et de compresser suffisamment, en acceptant des pertes que l’autre internaute ne verra jamais sur un Ă©cran non calibrĂ©, salis par les doigts, sous un Ă©clairage douteux et le plus souvent colorĂ© (dans les villes).

Il y a quelques mois, je pensais vous dĂ©crire les merveilles de Mozjpeg : les premiĂšres versions de Webp n’avaient pas convaincu Mozilla qui avait proposĂ© un nouvel algo et un nouvel outil, plutĂŽt efficace. En remplaçant purement et simplement la libjpeg, les gains en compression Ă©tait du mĂȘme niveau que Webp (Ă  l’époque), mais pour ceux qui aimaient jongler avec les paramĂštres2, les gains Ă©taient et sont toujours bien meilleurs. Tout le monde n’étant pas imageo-technophile, les feignants pouvaient se contenter d’utiliser ImageOptim pour un rĂ©sultat Ă©quivalent.

Aujourd’hui, mĂȘme les feignants n’ont pas d’excuses : Jpegli est super simple Ă  utiliser3, plus rapide et meilleur que Webp ou Avif, produit beaucoup moins d’artefacts classiques du Jpeg et se dĂ©code Ă  la vitesse de l’éclair puisque c’est du Jpeg normal. Et au sein d’XL-Converter c’est de la balle.

Je n’ai rien de plus à dire. En attendant Jpeg-XL dans tous nos navigateurs, Jpeg à la sauce Jpegli c’est trop bon, mangez-en.

En apéritif, goûtez donc cette petite note du divin Jon Sneyers :

More recently, the JPEG-XL team at Google has built yet another JPEG encoder, jpegli, which is both faster and better than even mozjpeg. It is based on lessons learned from guetzli and libjxl, and offers a very attractive trade-off: it is very fast, compresses better than WebP and even high-speed AVIF, while still producing good old JPEG files that are supported everywhere.


  1. voir ce paragraphe dans la doc sur les Core Web Vitals de Google. â†©

  2. les paramĂštres sont dans la source, use the force luke, read the code â†©

  3. disons plutĂŽt qu’il n’y a pas besoin d’autre paramĂštres que le niveau de compression pour ĂȘtre bien meilleur que Webp. â†©

Commentaires : voir le flux Atom ouvrir dans le navigateur

Transférer sa licence Windows dans une VM

N. D. M. : nlgranger nous explique dans le journal qui est repris pour cette dĂ©pĂȘche comment virtualiser un systĂšme prĂ©-installĂ©. Son expĂ©rience personnelle est relatĂ©e ici Ă  la premiĂšre personne (je). Rappelons aussi Ă  tout hasard que si la licence de ce systĂšme d’exploitation propriĂ©taire permet apparemment une utilisation dans le cadre d’une telle virtualisation, celle-ci doit ĂȘtre faite sur une seule instance et sans utilisation comme serveur (ce que rappelle aussi le tutoriel mentionnĂ© plus loin, mais sur une version prĂ©cĂ©dente du systĂšme). Et qu’il n’est possible de faire qu’une « seule copie du logiciel Ă  des fins de sauvegarde Â».

Je viens d’acheter un PC et bien que j’aie fouillĂ© et patientĂ© longtemps, aucune offre sans OS n’arrivait ou ne convenait donc j’ai cĂ©dĂ© Ă  la vente forcĂ©e d’un PC avec Windows.
Dans ce petit tutoriel, je vous explique comment dĂ©placer cette licence Windows OEM vers une machine virtuelle (VM) sur le mĂȘme PC. Si vous avez dĂ©jĂ  une licence achetĂ©e Ă  part, il vous suffit de la spĂ©cifier Ă  l’installation, on s’intĂ©resse ici au cas des licences OEM prĂ©installĂ©es sur la carte mĂšre.
L’intĂ©rĂȘt de dĂ©placer Windows dans une VM, c’est de ne pas bloquer une partie de l’espace disque avec une partition qui ne servira quasiment jamais. LĂ  on peut dĂ©placer l’image disque vers un stockage externe (disque ou clĂ© USB) ou recrĂ©er la VM au besoin.
Dans ce tutoriel j’utilise libvirt via le GUI virt-manager, mais je me suis largement appuyĂ© sur cet excellent tutoriel pour Proxmox d’Oliver Poncet que je vous invite Ă  consulter.
Je prĂ©cise immĂ©diatement qu’il n’est pas nĂ©cessaire d’avoir gardĂ© le Windows prĂ©installĂ© sur la machine, ni mĂȘme de l’avoir dĂ©marrĂ© une seule fois.

DĂ©pendances

Pour parvenir Ă  vos fins, il vous faudra les dĂ©pendances suivantes (en espĂ©rant ne rien oublier) :

  • dmidecode pour lire les infos de la carte mĂšre
  • libvirt
  • qemu/KVM
  • swtpm pour Ă©muler un TPM
  • edk2-ovmf pour Ă©muler un UEFI avec Secure Boot
  • Le fichier.iso de Windows 11 disponible sur le site de microsoft.

Sous ArchLinux : pacman – S dmidecode libvirt dnsmasq qemu-desktop swtmp

J’ai utilisĂ© virt-manager pour me faciliter la vie, j’imagine qu’on peut s’en sortir en ligne de commande directement avec qemu.

Installation

Récupérer les informations utiles

Pour valider automatiquement votre licence, Windows utilise des informations disponibles depuis la carte mĂšre.

D’abord, le numĂ©ro de sĂ©rie, modĂšle, etc. :

$ sudo dmidecode


BIOS Information
    Vendor : LENOVO
    Version : NCCN16WW
    Release Date : 02/02/2024


    BIOS Revision : 1.16
    Firmware Revision : 1.16


System Information
    Manufacturer : LENOVO
    Product Name : 83E3
    Version : Yoga Pro 7 14AHP9
    Serial Number : 9F5OEMTZ
    UUID : a0a73af8-a886-4fbf-8f0d-5fd32c264a16
    SKU Number : LENOVO_MT_83E3_BU_idea_FM_Yoga Pro 7 14AHP9
    Family : Yoga Pro 7 14AHP9

(j’ai Ă©ditĂ© le serial et l’uuid)

Ensuite des informations enregistrĂ©es dans des tables ACPI :

sudo cat /sys/firmware/acpi/tables/MSDM > ~/VMs/MSDM.bin
sudo cat /sys/firmware/acpi/tables/SLIC > ~/VMs/SLIC.bin

Créer la VM

La procĂ©dure dĂ©marre comme d’habitude, on suit l’assistant de virt-manager jusqu’au moment oĂč il faut bien demander Ă  modifier la configuration avant de dĂ©marrer.

Dans les options du BIOS, choisissez la config avec Secure Boot activĂ©, chez moi le fichier se nomme OVMF_CODE.secboot.4 m.fd.

Ensuite il faut Ă©diter directement le code XML qui dĂ©crit la configuration de la machine. Si c’est la premiĂšre fois dans virt-manager, il faut cocher une case dans les paramĂštres de l’appli pour le rendre Ă©ditable.

Pour commencer, modifiez le nƓud racine XML pour spĂ©cifier le schĂ©ma, sinon certaines options seront rejetĂ©es :

<domain type=“kvm” xmlns: qemu='http://libvirt.org/schemas/domain/qemu/1.0'>

Mettez aussi Ă  jour l’uuid pour qu’il corresponde Ă  celui indiquĂ© par dmidecode:

<uuid>a0a73af8-a886-4fbf-8f0d-5fd32c264a16</uuid>

Ensuite, il faut indiquer Ă  qemu d’intĂ©grer les tables ACPI :

<qemu: commandline>
<qemu: arg value='-acpitable'/>
<qemu: arg value='file=/home/ngranger/VMs/MSDM.bin'/>
<qemu: arg value='-acpitable'/>
<qemu: arg value='file=/home/ngranger/VMs/SLIC.bin'/>
</qemu: commandline>

Puis il faut ajouter les informations de la carte mĂšre :

<sysinfo type=“smbios”>
<bios>
<entry name=“vendor”>LENOVO</entry>
<entry name=“version”>NCCN16WW</entry>
<entry name=“date”>02/02/2024</entry>
<entry name=“release”>1.16</entry>
</bios>
<system>
<entry name=“manufacturer”>LENOVO</entry>
<entry name=“product”>83E3</entry>
<entry name=“version”>Yoga Pro 7 14AHP9</entry>
<entry name=“uuid”>a0a73af8-a886-4fbf-8f0d-5fd32c264a16</entry>
<entry name=“serial”>9F5OEMTZ</entry>
<entry name=“family”>Yoga Pro 7 14AHP9</entry>
<entry name=“sku”>LENOVO_MT_83E3_BU_idea_FM_Yoga Pro 7 14AHP9</entry>
</system>
</sysinfo>

Installation de Windows

La procédure est désormais habituelle.

Pour Ă©viter d’avoir Ă  utiliser un compte Microsoft, vous pouvez couper Internet au moment oĂč Windows redĂ©marre pour la configuration du systĂšme. Lorsque l’assistant en arrive Ă  la connexion au rĂ©seau, tapez Maj-F10 pour ouvrir le terminal et exĂ©cutez la commande oobe\BypassNRO. Le PC redĂ©marrera sur un assistant qui rend la connexion facultative.

Au démarrage, vous pourrez remettre Internet et vérifier que la licence est bien activée.

Commentaires : voir le flux Atom ouvrir dans le navigateur

Sortie de GIMP 2.99.18 (version de développement)

Note : cette dĂ©pĂȘche est une traduction de l'annonce officielle de la sortie de GIMP 2.99.18 du 21 fĂ©vrier 2024 (en anglais).

Voici enfin la derniĂšre version de dĂ©veloppement avant GIMP 3 ! Bien que la sortie de la version 2.99.18 soit un peu en retard par rapport au planning espĂ©rĂ©, celle-ci contient un certain nombre de fonctionnalitĂ©s et d'amĂ©liorations que nous sommes ravis de pouvoir partager avec vous.

⚠ â˜ąïž Nous vous rappelons qu'une version de dĂ©veloppement sert Ă  prĂ©senter les travaux en cours, mais vous permet aussi de dĂ©tecter et signaler les problĂšmes au plus tĂŽt. En d'autres termes, cette version est instable et nous ne recommandons pas son usage en production. Utilisez-lĂ  parce que vous voulez aider Ă  amĂ©liorer GIMP en signalant des bogues.

En particulier, cette version 2.99.18 est peut-ĂȘtre l'une des versions les plus instables de la sĂ©rie 2.99 Ă  cause du projet « space invasion Â» (NDT : « invasion venue de l'espace Â», un jeu de mots avec l'anglais colorspace signifiant espace de couleurs). Cela est parfaitement attendu et normal. ⚠ â˜ąïž

    Sommaire

    Cette dĂ©pĂȘche prĂ©sente les changements les plus notables et les plus visibles. En particulier, elle ne contient pas de liste exhaustive des correctifs de bogues ou des amĂ©liorations un peu moins importantes. Pour une liste plus complĂšte des changements, nous vous invitons Ă  consulter le fichier NEWS ou Ă  jeter un coup d’Ɠil Ă  l'historique du dĂ©pĂŽt Git.

    L'invasion de l'espace (des couleurs) !

    Nous avons travaillĂ© dur sur le projet Space Invasion, qui est — comme vous vous en rappelez peut-ĂȘtre — le nom de code que nous avons donnĂ© au projet visant Ă  rendre GIMP plus correct en ce qui concerne les couleurs.

    Ces derniers temps, nous avons réalisé le portage des anciennes structures de couleurs utilisées en interne (GimpRGB, GimpCMYK, GimpHSV
) dont nous nous servions pour stocker les informations de couleurs vers GeglColor. Cet objet générique peut contenir n'importe quelle donnée de couleur, quel que soit le modÚle colorimétrique, la précision ou l'espace, du moment que ceux-ci sont pris en charge par babl, notre moteur pour l'encodage des pixels.

    En ce qui concerne la justesse des couleurs, cela signifie que nous ferons maintenant les conversions de couleurs uniquement si cela est nĂ©cessaire (conversions Ă  la derniĂšre minute), ce qui permettra de ne pas perdre d'information lorsque cela peut ĂȘtre Ă©vitĂ©. Par exemple, imaginons que vous utilisiez la pipette Ă  couleurs sur une image : si nous convertissions cette couleur vers un format intermĂ©diaire avant de l'utiliser sur une autre image (qui peut avoir le mĂȘme format de couleurs ou un format diffĂ©rent), deux conversions auraient lieu. Cela augmente les possibilitĂ©s de perte de prĂ©cision. Ce problĂšme est encore plus flagrant si les formats d'entrĂ©e et de sortie sont les mĂȘmes (autrement dit, lorsqu'aucune conversion n'est nĂ©cessaire). Et cela sera encore plus problĂ©matique lorsque le modĂšle CMJN sera pris en charge nativement (nous voulons Ă©viter Ă  tout prix de faire un aller-retour entre un format intermĂ©diaire et le CMJN, qui n'a pas de relation bijective avec la plupart des autres modĂšles de couleurs, mĂȘme en travaillant sans bornes et en ignorant les problĂšmes de prĂ©cision).

    DĂ©finition d'un espace non bornĂ© (ajout par rapport Ă  la dĂ©pĂȘche originelle) : lorsque la prĂ©cision est entiĂšre, l'espace est toujours bornĂ© (par exemple [0-255] en 8-bit). Par contre, en flottant, oĂč l'espace de travail standard est [0, 1], on peut dĂ©cider d'accepter les valeurs nĂ©gatives et supĂ©rieures Ă  1. Cela rend les conversions entre beaucoup d'espaces de couleurs bijectives, aux erreurs de prĂ©cisions prĂšs. Notamment, les conversions entre deux espaces RVB, ou mĂȘme un espace RVB et divers autres modĂšles, deviennent bijectives. Ce n'est pas le cas entre RVB et CMJN, mĂȘme en espace de couleurs infini.

    Nous sommes Ă©galement en train de migrer le stockage des donnĂ©es de couleur vers ce type d'objet gĂ©nĂ©rique. Cela signifie entre autres que les palettes de couleurs pourront comporter des couleurs au format CMJN, CIELAB ou bien encore dans tout autre modĂšle pris en charge (et pas seulement ces couleurs aprĂšs une Ă©tape de conversion vers le sRVB non bornĂ© - « unbounded sRGB Â»).

    Une consĂ©quence pour la maintenance logicielle est qu'il sera beaucoup plus facile de gĂ©rer les conversions de couleurs au sein de notre code, Ă©tant donnĂ© que cette structure comprend Ă  la fois les donnĂ©es et leur « signification Â». Cela rend la gestion des couleurs beaucoup moins susceptible d'introduire des bogues par rapport Ă  l'approche prĂ©cĂ©dente, qui consistait Ă  faire suivre les deux types d'information sĂ©parĂ©ment.

    Finalement, nous travaillons Ă  faire apparaĂźtre l'information concernant l'espace de couleurs Ă  plusieurs endroits de l'interface oĂč cela est pertinent, par exemple lorsque des donnĂ©es RVB, CMJN, TSL ou TSV sont affichĂ©es ou peuvent ĂȘtre choisies. Les valeurs brutes dans ces modĂšles de couleurs en l'absence de la connaissance de l'espace de couleurs associĂ© n'ont pratiquement aucun sens. L'affichage dans l'interface de valeurs RVB sans autre prĂ©cision est un reliquat du passĂ©, lorsque cela signifait le plus souvent sRVB. Cela n'est plus vrai dans un contexte graphique moderne et l'interface devrait ĂȘtre claire Ă  ce sujet.

    La vidĂ©o ci-dessous montre quelques aspects de ce travail sur l'interface, par exemple le fait que les modĂšles RVB, TSV ou CMJN affichent Ă  tout instant l'espace de couleurs dans lequel les valeurs sont considĂ©rĂ©es (ce qui trĂšs souvent correspond au nom du profil ICC). Cela est dĂ©jĂ  fait pour la pipette Ă  couleurs, les Ă©chantillons de couleurs, l'ancrable des couleurs de premier/d'arriĂšre plan, la boĂźte de dialogue « Changer la couleur de premier/d'arriĂšre plan Â», ainsi qu'Ă  d'autres endroits.

    Non seulement cela, mais lorsque les gens sĂ©lectionnent un profil d’épreuve sur Ă©cran et activent l'Ă©preuve sur Ă©cran (par exemple grĂące Ă  la nouvelle bascule de simulation qui a Ă©tĂ© ajoutĂ©e dans GIMP 2.99.12), nous afficherons Ă©galement non seulement la zone hors gamme de l'espace colorimĂ©trique de l'image, mais Ă©galement celle de l'espace d’épreuve.

    Invasion de l'espace dans l'interface - GIMP 2.99.18
    Invasion de l'espace dans l'interface - GIMP 2.99.18 (cliquez sur l'image pour voir la vidéo sur le compte Peertube de GIMP)

    Avertissement trĂšs important : il s'agit encore une fois d'un portage Ă©norme dans notre base de code, ce qui a impactĂ© littĂ©ralement des milliers de lignes de code. Ce travail est inachevĂ© mais il devra ĂȘtre terminĂ© avant la premiĂšre version candidate. Des instabilitĂ©s ou des bugs sont Ă  prĂ©voir dans cette mise Ă  jour donc si vous rencontrez un problĂšme, nous recommandons de le rapporter.

    Amélioration des algorithmes de couleur

    Øyvind KolÄs a amélioré quelques algorithmes internes :

    • Les pixels achromatiques de l'outil Teinte-Saturation sont dĂ©sormais un cas spĂ©cial afin que les pixels en niveaux de gris (saturation de 0) ne soient modifiĂ©s que par le rĂ©glage principal, pas par le rĂ©glage rouge.
    • Les dĂ©gradĂ©s en niveaux de gris restent dĂ©sormais achromatiques mĂȘme avec "Tramage" cochĂ© dans l'outil DĂ©gradĂ©.

    Au fur et à mesure que le projet space invasion avance, obtenir des résultats cohérents devient plus facile dans divers algorithmes liés aux couleurs, nous permettant ainsi de découvrir rapidement les problÚmes et de les résoudre.

    Édition non-destructive, premiùre mouture

    Un domaine dans lequel nous sommes « en avance sur le planning Â» est l'Ă©dition non destructive, qui Ă©tait trĂšs demandĂ©e ! Les fondations de ces fonctionnalitĂ©s ont Ă©tĂ© mises en place par de nombreux dĂ©veloppeurs au cours de nombreuses annĂ©es, depuis l'introduction de GEGL dans GIMP. Bien qu'initialement prĂ©vue pour la feuille de route de la version 3.2, une premiĂšre implĂ©mentation a vu le jour en tant que continuation d'un projet Google Summer of Code. Si vous n'ĂȘtes pas familier avec ce terme, « Ă©dition non destructive Â» implique notamment que des effets de filtres tels qu'un effet de flou sont stockĂ©s sĂ©parĂ©ment des pixels du calque. Cela signifie que si vous dĂ©sirez plus tard modifier un rĂ©glage, rĂ©arranger ou mĂȘme retirer le filtre, vous pouvez le faire trĂšs facilement sans affecter le reste de l'image. Jusqu'Ă  prĂ©sent, GIMP utilisait une procĂ©dure d'Ă©dition destructive oĂč les effets Ă©taient immĂ©diatement appliquĂ©s sur le calque, c'est donc un changement majeur !

    Toute opĂ©ration GEGL munie d'une interface graphique est dĂ©sormais appliquĂ©e aux calques de maniĂšre non destructive. (Les effets non destructifs pour les masques de calques et les canaux sont prĂ©vus pour les versions ultĂ©rieures.) Cela inclut les greffons GEGL tiers et les opĂ©rations personnalisĂ©es crĂ©Ă©es avec notre outil GEGL Graph. Ces effets peuvent ĂȘtre sauvegardĂ©s et chargĂ©s via les fichiers de projet .xcf, bien que toutes les propriĂ©tĂ©s GEGL ne soient pas encore prises en charge dans la version actuelle.

    Une fois qu'un filtre a Ă©tĂ© appliquĂ©, vous pouvez continuer Ă  interagir avec lui en cliquant sur l'icĂŽne de filtre dans l'ancrable des calques. Cela ouvrira une boĂźte de dialogue montrant tous les filtres actuellement appliquĂ©s au calque. À partir de lĂ , vous pouvez alterner l'Ă©tat de visibilitĂ© du filtre, modifier ses rĂ©glages, rĂ©ordonner les filtres et retirer les effets un Ă  un. Vous pouvez aussi fusionner tous les filtres et les appliquer Ă  l'image pour retrouver une procĂ©dure d'Ă©dition destructive.

    Effets non destructifs - GIMP 2.99.18
    Effets non destructifs - GIMP 2.99.18 (cliquez sur l'image pour voir la vidéo sur le compte Peertube de GIMP)

    Notez bien que tout cela est seulement une premiĂšre implĂ©mentation, et beaucoup de travail reste Ă  faire pour disposer d'une Ă©dition non destructive complĂšte et riche. Nous allons continuer Ă  affiner les fonctionnalitĂ©s existantes pour la sortie de la version 3.0 en nous basant sur les tests et les retours des utilisateurs, et nous les dĂ©velopperons davantage par la suite. L'interface elle-mĂȘme ne correspond pas Ă  notre vision idĂ©ale de cette fonctionnalitĂ©, et un premier jet de spĂ©cifications a Ă©tĂ© Ă©crit pour dĂ©finir un processus d'Ă©dition bien plus intĂ©grĂ©.

    La capture d'Ă©cran ci-dessous est une maquette rĂ©alisĂ©e Ă  partir de ces premiĂšres spĂ©cifications. Elle montre les effets de calque placĂ©s au sein de la liste principale des calques, partageant les mĂȘmes boutons « Ć“il Â» et « cadenas Â», mais Ă©galement avec leurs propres masques faciles Ă  Ă©diter :

    Maquette des spécifications pour l'application non-destructive d'effets de calque

    Maquette des spécifications : les effets de calque sont visibles directement dans la liste des calques, avec leur propres masques

    NĂ©anmoins, l'implĂ©mentation de cette nouvelle interface sera un dĂ©fi en elle-mĂȘme et nous avons donc dĂ©cidĂ© de la remettre Ă  aprĂšs la sortie de GIMP 3 et de proposer cette premiĂšre mouture en premier lieu.

    N'hĂ©sitez pas Ă  partager vos opinions dans les forums de discussion et dans le suivi des incidents !

    Amélioration de la prise en charge des polices de caractÚres

    Idriss Fekir, un autre étudiant du GSoC 2023, a travaillé avec Liam Quinn, un développeur de longue date, sur l'amélioration de la prise en charge des polices de caractÚres par GIMP. Une grande partie de ce travail concerne le code interne de GIMP afin d'améliorer sa capacité à gérer les futures mises à jour de polices et de texte. Certains changements plus visibles sont par exemple :

    • GIMP n'a plus besoin que les noms des polices de caractĂšres soient uniques pour pouvoir les distinguer les unes des autres. Cela signifie qu'il n'ajoutera plus « #1 Â», « #2 Â» et ainsi de suite, mais gardera Ă  prĂ©sent les noms originaux dans la liste de sĂ©lection des polices. MalgrĂ© des noms apparemment identiques, deux polices avec le mĂȘme nom fonctionneront dĂ©sormais correctement.
    • GIMP peut maintenant charger des polices avec des styles personnalisĂ©s (en contournant l'utilisation de Pango qui n'est pas capable de les charger).
    • Nous pouvons Ă  prĂ©sent charger davantage de types de polices qu'auparavant. Si jamais nous ne prenons pas encore en charge une police donnĂ©e (ou si elle est inexistante), nous sommes mieux Ă  mĂȘme de le dĂ©tecter et nous pouvons nous replier sur une police par dĂ©faut. Cela permet d'amĂ©liorer la prise en charge d'un fichier .xcf crĂ©Ă© sur un autre ordinateur avec diffĂ©rentes polices disponibles.
    • Sous Windows, nous forçons le moteur Pango Ă  toujours utiliser l'anticrĂ©nelage. Cela augmente la lisibilitĂ© du texte des menus sous ce systĂšme d'exploitation, en particulier lorsqu'un thĂšme sombre est utilisĂ©.
    • Le code pour la sauvegarde au format XCF stocke dĂ©sormais les informations concernant les polices de maniĂšre bien plus prĂ©cise, ce qui aide Ă  Ă©viter de charger une police incorrecte lors de la rĂ©ouverture d'un fichier XCF.
    • L'alignement du texte dans les calques de texte pour les langues Ă©crites de la droite vers la gauche est maintenant plus cohĂ©rent avec la maniĂšre dont cela fonctionne dans d'autres programmes (par exemple LibreOffice et Scribus).

    Ces changements sont beaucoup moins voyants que certaines autres fonctionnalités et pourraient sembler moins importants, mais ils constituent en fait les fondations qui permettront d'avoir une gestion du texte bien plus fiable dans GIMP. Notre vision pour le futur est d'avoir une édition de texte plus simple tout en étant plus puissante et plus riche en fonctionnalités (en particulier les fonctionnalités OpenType qui sont quelques-unes des améliorations majeures que nous espérons ajouter un jour ou l'autre).

    Expansion automatique des calques

    Le troisiĂšme projet GSoC de l'Ă©tĂ© dernier par l'Ă©tudiant Shubham Daule a apportĂ© une fonctionnalitĂ© demandĂ©e depuis longtemps : l'expansion automatique de calques ! Les outils de peinture ont dĂ©sormais une option supplĂ©mentaire « Ă‰tendre les calques Â». Lorsque cette case est cochĂ©e, peindre au-delĂ  des limites des calques les fera s'Ă©tendre automatiquement afin que vous n'ayez pas Ă  gĂ©rer vous-mĂȘme la taille du calque. Si vous souhaitez Ă©tendre le calque au-delĂ  de la taille actuelle du canevas, vous devrez Ă©galement cocher l'option « Afficher tout Â» dans le menu Affichage.

    Calques à expansion automatique - démonstration de GIMP 2.99.18
    Calques à expansion automatique - GIMP 2.99.18 (cliquez sur l'image pour voir la vidéo sur le compte Peertube de GIMP)

    L'option d'expansion des calques comporte Ă©galement des paramĂštres supplĂ©mentaires lorsqu'elle est sĂ©lectionnĂ©e. Vous pouvez dĂ©cider dans quelle mesure vous souhaitez que les limites du calque s'Ă©tendent chaque fois que le pinceau les atteint. Il existe Ă©galement des options pour spĂ©cifier comment les nouvelles zones du calque et du masque de calque doivent ĂȘtre remplies une fois Ă©tendues.

    Nouvelles options d'alignement

    Le nouveau contributeur mr. fantastic a dĂ©veloppĂ© deux nouvelles options pour aligner les calques sur le canevas. Avec « Snap to Bounding Boxes Â» (« Aligner sur les boĂźtes englobantes Â») activĂ©, des guides dynamiques s'afficheront dĂ©sormais pour vous montrer quand le calque que vous dĂ©placez est alignĂ© avec le centre ou les cĂŽtĂ©s des autres. Le calque actif s'alignera Ă©galement sur ces bordures pour vous aider Ă  les organiser correctement. La deuxiĂšme option, « Snap to Equidistance Â» (« Aligner Ă  Ă©quidistance Â»), vous permet un alignement entre trois calques Ă©quidistants les uns des autres.

    Aligner sur les boßtes englobantes et Aligner à équidistance - démonstration de GIMP 2.99.18
    Nouvelles options d'alignement automatique - GIMP 2.99.18 (cliquez sur l'image pour voir la vidéo sur le compte Peertube de GIMP)

    ThĂšmes

    Nous avons continuĂ© Ă  amĂ©liorer l'interface utilisateur et le style de cette version. L’une des amĂ©liorations les plus importantes concernait la gestion des « fuites de thĂšmes systĂšme Â». Il existe des styles qui n'ont pas Ă©tĂ© spĂ©cifiquement dĂ©finis dans nos thĂšmes, donnant ainsi l'opportunitĂ© aux rĂšgles de style du thĂšme systĂšme de "fuiter" de maniĂšre conflictuelle dans notre interface. Avec l’aide et les retours de plusieurs contributeurs et utilisateurs, nous avons beaucoup progressĂ© dans la dĂ©finition de ces styles afin que tous aient une expĂ©rience cohĂ©rente !

    RĂ©cemment, Jehan a travaillĂ© sur la rĂ©organisation et la simplification de notre systĂšme de thĂšmes. Dans les versions de dĂ©veloppement prĂ©cĂ©dentes, nous avions cinq thĂšmes diffĂ©rents : Par DĂ©faut, Gris, SystĂšme, Plus Sombre et Compact (chacun avec des options claires et sombres). Ceux-ci ont Ă©tĂ© simplifiĂ©s dans le thĂšme SystĂšme et un seul thĂšme par dĂ©faut avec trois Ă©tats possibles : clair, foncĂ© et gris. De mĂȘme, nos quatre thĂšmes d'icĂŽnes distincts ont Ă©tĂ© condensĂ©s dans l'ensemble Legacy et un thĂšme d'icĂŽns par dĂ©faut avec des variantes couleur et symbolique. Nous pensons que ces changements rĂ©duiront la confusion des utilisateurs et leur permettront de trouver plus facilement leur apparence d'interface prĂ©fĂ©rĂ©e.

    De plus, sous Windows, la barre de titre principale (et la plupart des barres de titre des boßtes de dialogue) s'ajuste désormais au mode clair ou sombre en fonction du thÚme sélectionné.

    BoĂźte de dialogue de bienvenue

    La boßte de dialogue de bienvenue a été étendue pour fournir un accÚs rapide à un certain nombre de fonctionnalités et d'options utiles. Elle comporte ainsi quatre nouvelles sections :

    • Personnaliser : Plusieurs options de personnalisation nĂ©cessitent de fouiller dans la boĂźte de dialogue des PrĂ©fĂ©rences pour ĂȘtre modifiĂ©es. À prĂ©sent, vous pouvez facilement modifier les thĂšmes de couleurs et d'icĂŽnes, la langue et la taille de la police de l'interface utilisateur, ainsi que certains rĂ©glages en fonction du systĂšme d'exploitation.
    • CrĂ©er : Cette section affiche les huit images que vous avez ouvertes en dernier et vous permet de les rouvrir rapidement. Des boutons pour crĂ©er une nouvelle image ou pour en charger une existante sont Ă©galement prĂ©sents. À l'instar d'autres programmes, vous pouvez demander Ă  ce que cet Ă©cran apparaisse automatiquement au dĂ©marrage de GIMP pour un accĂšs direct Ă  ces fonctionnalitĂ©s.
    • Contribuer : Nous avons rĂ©uni ici quelques-unes des nombreuses façons dont vous pouvez participer au dĂ©veloppement de GIMP. Cette section comporte des liens pour le signalement de bogues, pour Ă©crire du code, pour aider aux traductions ou pour faire un don.
    • Notes de version : PrĂ©cĂ©demment, le lien vers ces notes Ă©taient affichĂ©es dans la moitiĂ© infĂ©rieure de la boĂźte de dialogue de bienvenue. À prĂ©sent, nous avons un onglet entier dĂ©diĂ© Ă  ces notes pour une lecture plus aisĂ©e.

    Formats de fichiers

    Comme cela était déjà le cas avec les versions précédentes, nous avons amélioré la prise en charge de formats de fichiers déjà existants et nous avons ajouté la prise en charge de l'importation et de l'exportation pour de nouveaux formats.

    DDS

    Stayd, un nouveau contributeur, a travaillĂ© avec notre dĂ©veloppeur Jacob Boerema pour apporter de nombreuses amĂ©liorations au greffon DDS. Pour commencer, les fonctions d'importation ont Ă©tĂ© Ă©crites afin d'ĂȘtre plus simples et plus faciles Ă  Ă©tendre dans le futur. Les mises Ă  jour supplĂ©mentaires incluent Ă©galement :

    • Le chargement d'images DDS RVBA 16 et 32 bits/canal est maintenant possible.
    • Le filtre cubique Catmull-Rom a Ă©tĂ© ajoutĂ© pour la gĂ©nĂ©ration de mipmaps, et tous les calculs pour gĂ©nĂ©rer les mipmaps sont effectuĂ©s avec une prĂ©cision de 32 bits.
    • Les images DDS aux formats R8G8, R16 et R16G16 peuvent maintenant Ă©galement ĂȘtre chargĂ©es.
    • Une option pour renverser verticalement les images DDS lors de l'importation a Ă©tĂ© ajoutĂ©e pour faire Ă©cho Ă  l'option d'exportation correspondante, Ă©tant donnĂ© que certaines images de jeux stockent leurs donnĂ©es de cette maniĂšre.

    GIF

    Par le passé, écraser un fichier GIF à la sauvegarde (plutÎt que de l'exporter) le convertissait systématiquement en un fichier avec une seule image. Désormais nous vérifions lors du chargement si le fichier GIF est une animation, de maniÚre à également sauvegarder une animation lors de l'écrasement.

    HEIF et JPEG-XL

    Les deux greffons utilisent maintenant leurs bibliothÚques respectives (libheif et libjxl) pour le chargement des métadonnées. Cela nous a permis de retirer notre code maison chargé d'interpréter l'orientation des images et d'utiliser à la place les informations fournies par ces bibliothÚques.

    OpenEXR

    Le format OpenEXR permet aux canaux d'avoir des noms personnalisés, outre le type de couleur. Dans ce cas, nous considérons maintenant toute image à un seul canal avec un nom non conventionnel comme étant en niveaux de gris. Lors de l'importation, nous affichons une notification afin que les utilisateurs soient prévenus de cette conversion.

    PDF

    L'option d'exportation « Calques en tant que pages Â» fonctionne maintenant mĂȘme s'il y a un seul groupe de calques. Auparavant, cette option n'Ă©tait pas disponible car le greffon vĂ©rifiait seulement s'il y avait plus d'un « calque Â» sans examiner s'il s'agissait d'un groupe de calques avec de multiples sous-calques.

    PNG

    Les fragments de fichiers PNG qui sont « copiables sans risque Â» (« safe-to-copy chunks Â») sont maintenant prĂ©servĂ©s lors de l'importation et inclus dans l'image exportĂ©e. Un autre souci qui existait lors de l'exportation de PNGs indexĂ©s avec transparence (et qui nous avait Ă©tĂ© souvent signalĂ©) a Ă©tĂ© rĂ©solu. DĂ©sormais les couleurs indexĂ©es devraient ĂȘtre affichĂ©es correctement aprĂšs exportation.

    PSD

    Jacob Boerema a poursuivi son travail d'amélioration du greffon PSD. En plus d'avoir résolu des bogues, par exemple dans l'ordre des calques lors de l'importation, il a aussi clarifié l'avertissement présenté lors de l'exportation et concernant la compatibilité des modes de calques entre GIMP et Photoshop.

    PSP

    Le greffon Paintshop Pro peut maintenant importer davantage de caractéristiques depuis un fichier projet, comme par exemple le profil de couleurs ICC, les guides, les grilles, et la sélection active lors de la sauvegarde. Les failles de sécurité ZDI-CAN-22096 et ZDI-CAN-22097 ont également été corrigées dans cette version.

    Nouveaux formats d'image pris en charge : Farbfeld, Esm Software PIX, HEJ2

    Nous avons rĂ©cemment ajoutĂ© la prise en charge de l'importation et de l'exportation pour le format Farbfeld, un format d'image sRVB conçu pour ĂȘtre facile Ă  lire, Ă  envoyer dans des pipes et Ă  compresser avec des outils tiers.

    Nous avons aussi ajouté la prise en charge de l'importation seule pour les nouveaux formats suivants :

    • Esm Software PIX : Un format JPEG modifiĂ© utilisĂ© exclusivement par l'entreprise Esm Software pour stocker leurs images propres. Cela a Ă©tĂ© implementĂ© en rĂ©ponse Ă  un signalement de bogue qui avait confondu ce format avec le format Alias PIX que nous prenions dĂ©jĂ  en charge.
    • HEJ2 : Un ajout Ă  notre greffon HEIF dĂ©jĂ  existant fourni par Daniel NovomeskĂœ qui permet d'importer des images JPEG 2000 compressĂ©es.

    Nouveau format de palette pris en charge : Swatchbooker

    Swatchbooker est un programme libre de crĂ©ation et de conversion de palettes de couleurs qui prend en charge de nombreux formats. Bien que le programme lui-mĂȘme n'ait pas Ă©tĂ© mis Ă  jour depuis de nombreuses annĂ©es, son format de palette propre .sbz est le plus complet de tous ceux que nous prenons en charge actuellement. Parmi ses nombreuses fonctionnalitĂ©s, on peut citer la possibilitĂ© de dĂ©finir des couleurs dans plusieurs modĂšles de couleurs pour chaque entrĂ©e d'une palette, des noms et des descriptions rĂ©gionalisables, et la prise en charge de profils de couleurs ICC diffĂ©rents pour chaque entrĂ©e.

    Via notre travail sur la prise en charge de son importation, nous avons pu fournir des informations qui ont conduit Ă  un correctif de bogue dans la prise en charge de Swatchbooker par Krita. C'est toujours sympa quand des projets peuvent collaborer et s'entraider !

    Interactions avec les pads de tablettes graphiques sous Wayland

    Carlos Garnacho, un contributeur GNOME de longue date, a ajoutĂ© la prise en charge de l'interaction directe des boutons de tablettes graphiques (pad) avec GIMP. Quand une tablette est branchĂ©e, vous pouvez dĂ©sormais assigner diffĂ©rentes actions aux contrĂŽles de la tablette depuis la boĂźte de dialogue « PĂ©riphĂ©riques d'entrĂ©e Â» dans le menu Édition.

    Assigner des actions aux boutons d'une tablette graphique
    Assigner des actions aux boutons d'une tablette graphique - GIMP 2.99.18

    Ce travail a aussi impliqué le portage de fonctionnalités vers GTK 3, la boßte à outils utilisée par GIMP pour son interface graphique. Notez que cette fonctionnalité est seulement disponible sous Wayland pour le moment.

    Mise Ă  jour de l'API

    L'interface de programmation d'application (API), destinĂ©e aux crĂ©ateurs de greffons, est rĂ©guliĂšrement retravaillĂ©e dans le cadre de la refonte de GIMP 3. Une partie de ce travail est de migrer l'API vers l'utilisation de GeglColor lorsque les couleurs sont impliquĂ©es, ce qui entre dans le cadre plus gĂ©nĂ©ral du projet Space Invasion. MalgrĂ© tout, ce n’est qu’une petite partie de l’ensemble des amĂ©liorations de l’API.

    Nous nous orientons Ă©galement vers plus de classes pour reprĂ©senter les diffĂ©rentes ressources gĂ©rĂ©es par GIMP (pinceaux, polices, motifs, etc.) au lieu de les reprĂ©senter uniquement par des noms (ce qui Ă©tait une limitation historique alors qu'il est tout Ă  fait possible Ă  2 crĂ©ateurs de ressources de choisir le mĂȘme nom et le fait est que nous voyons de tels cas dans la nature — par exemple, 2 polices crĂ©Ă©es indĂ©pendamment peuvent avoir le mĂȘme nom).

    Un autre grand pas consiste à remplacer le GimpValueArray représentant les arguments ordonnés d'une procédure d'un greffon par un GimpProcedureConfig qui contient les arguments par nom plutÎt que par ordre. Cela permet une utilisation beaucoup plus sémantique des procédures de greffon (surtout lorsqu'elles ont une longue liste d'arguments) et facilitera également l'amélioration des greffons à l'avenir, avec des arguments nouveaux ou réorganisés sans créer de nouvelles procédures, car l'ordre et le nombre des arguments comptent beaucoup moins. Cela signifie que l'ajout de nouveaux arguments dans le futur ne brisera plus les scripts déjà existants qui dépendaient des versions antérieures de ces greffons (les auteurs de greffons devront toujours choisir des valeurs par défaut appropriées pour les nouveaux arguments afin que cela soit vrai, bien sûr).

    En parallĂšle, nous continuons d'amĂ©liorer la capacitĂ© de crĂ©ation automatique d'interfaces graphiques offerte aux greffons, rendant la crĂ©ation de boĂźtes de dialogue plus simple que jamais. Cela inclut (parmi de nombreuses autres amĂ©liorations) un nouveau type d'argument de procĂ©dure nommĂ© GimpChoice qui est une liste de choix sous forme de chaĂźnes de caractĂšres qui peut ĂȘtre prĂ©sentĂ©e aux crĂ©ateurs sous forme de widgets de liste dĂ©roulante dans la boĂźte de dialogue de votre greffon.

    Nous prĂ©voyons d'Ă©crire et de publier un didacticiel pour les rĂ©dacteurs de greffons dans la section DĂ©veloppement de ressources de notre site Web pour dĂ©veloppeur en mĂȘme temps que la sortie de GIMP 3, ou peu de temps aprĂšs.

    GEGL et babl

    Cette version de GIMP est accompagnée de nouvelles versions de GEGL et babl, qui contribuent toutes deux au projet (Color) Space Invasion.

    babl 0.1.108 apporte une nouvelle fonction babl_space_is_rgb pour nous aider à confirmer directement qu'un espace colorimétrique est RVB (plutÎt que de faire plusieurs tests pour voir s'il n'est pas CMJN ou niveaux de gris). Plusieurs améliorations ont également été apportées au processus de compilation et à l'outil d'interface de ligne de commande de babl.

    GEGL 0.4.48 fournit plusieurs mises à jour de l'objet GeglColor qui prend désormais en charge une grande partie des opérations de couleur de GIMP. Les améliorations spécifiques incluent la possibilité d'obtenir et de définir directement les valeurs de couleur CMJN, ainsi que l'attribution de l'espace colorimétrique lors de la définition des couleurs RVB(A).

    Un crash dans le filtre gegl:voroni existant a Ă©tĂ© corrigĂ©, et un bogue de longue date avec le filtre gegl:dropshadow qui empĂȘchait l'effet de rĂ©trĂ©cir a Ă©galement Ă©tĂ© corrigĂ©.

    Enfin, un nouveau filtre gegl:shuffle-search a été ajouté à l'atelier. Il mélange les pixels voisins pour créer un effet de tramage plus optimisé.

    Statistiques de sortie

    Hormis la premiÚre version de la série (2.99.2), GIMP 2.99.18 est clairement la plus grosse mise à jour à bien des égards. Depuis la version 2.99.16 :

    • 238 rapports ont Ă©tĂ© clĂŽturĂ©s comme CORRIGÉS.
    • 201 demandes de fusion ont Ă©tĂ© acceptĂ©es.
    • 1358 commits ont Ă©tĂ© poussĂ©s.
    • 26 traductions ont Ă©tĂ© mises Ă  jour : allemand, basque, biĂ©lorusse, portugais brĂ©silien, bulgare, catalan, chinois (Chine), danois, espagnol, espĂ©ranto, finnois, gĂ©orgien, grec, hongrois, islandais, italien, lituanien, norvĂ©gien nynorsk, persan, polonais, russe , slovĂšne, suĂ©dois, turc, ukrainien, vietnamien.

    60 personnes ont apporté des modifications ou des correctifs à la base de code de GIMP 2.99.18 (l'ordre est déterminé par le nombre de commits; certaines personnes apparaissent dans plusieurs groupes) :

    • 23 dĂ©veloppeurs pour le code principal : Jehan, Alx Sa, Shubham, Jacob Boerema, Idriss Fekir, bootchk, Anders Jonsson, Carlos Garnacho, mr.fantastic, Stanislav Grinkov, lillolollo, Øyvind KolĂ„s, Sabri Ünal, programmer_ceds, Lukas Oberhuber, programmer-ceds, James Golden, Luca Bacci, Massimo Valentini, Niels De Graef, Zander Brown, psykose, sonia.
    • 17 dĂ©veloppeurs de greffons ou de modules : Jehan, Alx Sa, Jacob Boerema, bootchk, Anders Jonsson, Stayd, Zander Brown, Bruno Lopes, Daniel NovomeskĂœ, Sabri Ünal, programmer_ceds, Kamil Burda, Mark, Michael Schumacher, Stanislav Grinkov, programmer-ceds, sonia.
    • 31 traducteurs : Yuri Chornoivan, Martin, Ekaterine Papava, Luming Zh, Sabri Ünal, Anders Jonsson, Rodrigo LledĂł, Jordi Mas, Alan Mortensen, Vasil Pupkin, Asier Sarasua Garmendia, KolbjĂžrn StuestĂžl, Boyuan Yang, VĂ­ttor Paulo Vieira da Costa, dimspingos, Alexander Shopov, Alexandre Prokoudine, Aurimas Černius, BalĂĄzs Úr, Marco Ciampa, Sveinn Ă­ Felli, Danial Behzadi, Ngọc QuĂąn Tráș§n, JĂŒrgen Benvenuti, Piotr Drąg, Timo Jyrinki, Andre Klapper, Kristjan SCHMIDT, MohammadSaleh Kamyab, Rafael Fontenelle, Tim Sabsch.
    • 9 crĂ©ateurs de ressources (icĂŽnes, thĂšmes, curseurs, splash screen, mĂ©tadonnĂ©es
) : Alx Sa, Jehan, Ferry JĂ©rĂ©mie, Stanislav Grinkov, Anders Jonsson, Bruno Lopes, Jacob Boerema, Sabri Ünal, mr.fantastic.
    • 5 contributeurs Ă  la documentation : Jehan, Bruno Lopes, Jacob Boerema, Alx Sa, Anders Jonsson.
    • 14 contributeurs pour la compilation, l'empaquetage ou l'intĂ©gration continue : Jehan, Bruno Lopes, bootchk, Alx Sa, Zander Brown, Jacob Boerema, Jacob Boerema, Stayd, Carlos Garnacho, Heiko Becker, mr.fantastic, Daniel NovomeskĂœ, U-YGGDRASIL\ender, lillolollo.

    Contributions à d'autres dépÎts du GIMPverse (l'ordre est déterminé par le nombre de commits) :

    • babl 0.1.108 est composĂ© de 17 commits par 6 contributeurs : Jehan, Øyvind KolĂ„s, John Marshall, Andre Klapper, John, sid.
    • GEGL 0.4.48 est composĂ© de 77 commits par 20 contributeurs : Øyvind KolĂ„s, Jehan, Anders Jonsson, Jacob Boerema, Yuri Chornoivan, Alan Mortensen, Sabri Ünal, Andre Klapper, Ekaterine Papava, Jan Tojnar, Jordi Mas, Luming Zh, Martin , Piotr Drąg, VĂ­ttor Paulo Vieira da Costa, Asier Sarasua Garmendia, Marco Ciampa, Rodrigo LledĂł, dimspingos, woob.
    • ctx a eu 308 commits depuis la version 2.99.14 par 1 contributeur : Øyvind KolĂ„s.
    • La version gimp-macos-build (scripts d'empaquetage macOS) est composĂ©e de 32 commits par 1 contributeur : Lukas Oberhuber.
    • La version flatpak est composĂ©e de 15 commits par 3 contributeurs : Jehan, Daniel NovomeskĂœ et Hubert FiguiĂšre.
    • Notre site Web principal a eu 31 commits depuis la sortie du 2.10.36 par 6 contributeurs : Jehan, Alx Sa, Sabri Ünal, Anders Jonsson, Bruno Lopes, Jonathan Demeyer.
    • Notre site Web des dĂ©veloppeurs a eu 30 commits depuis la version 2.10.36 par 5 contributeurs : Bruno Lopes, Jehan, Alx Sa, bootchk, Robin Swift.
    • Notre documentation 3.0 a enregistrĂ© 247 commits depuis la version 2.99.16 par 17 contributeurs : Andre Klapper, Jacob Boerema, Yuri Chornoivan, Alx Sa, Jordi Mas, Alan Mortensen, Dimspingos, Anders Jonsson, Boyuan Yang, Sabri Ünal, VĂ­ttor Paulo Vieira da Costa, Juliano de Souza Camargo, Rodrigo LledĂł, KolbjĂžrn StuestĂžl, Marco Ciampa, Danial Behzadi, Emin Tufan Çetin.

    N'oublions pas de remercier toutes les personnes qui nous aident Ă  faire le tri dans Gitlab, rapportent des bogues et discutent avec nous d'Ă©ventuelles amĂ©liorations. Notre communautĂ© est Ă©galement profondĂ©ment reconnaissante envers les guerriers d'Internet qui gĂšrent nos diffĂ©rents canaux de discussion ou comptes de rĂ©seaux sociaux tels que Ville PĂ€tsi, Liam Quin, Michael Schumacher et Sevenix !

    Remarque : compte tenu du nombre de piÚces qui composent GIMP et son environnement, et de la maniÚre dont nous obtenons des statistiques via des scripts git, des erreurs peuvent se glisser dans ces statistiques. N'hésitez pas à nous dire si nous avons manqué ou mal catégorisé certains contributeurs ou contributions.

    Nouvelles de l'équipe et procédure de sortie

    Les droits d'accÚs au dépÎt git ont été récemment accordés à Bruno Lopes (qui a été trÚs actif dans l'amélioration de notre processus de compilation et de l'empaquetage pour Windows).

    Plusieurs développeurs ou empaqueteurs de longue date ou plus récents qui ont commencé à contribuer au nouveau site Web des développeurs ont également reçu l'accÚs au dépÎt git associé.

    De plus en plus de contributeurs participent dĂ©sormais activement aux tests des versions et du processus d'empaquetage, et c'est la premiĂšre dĂ©pĂȘche depuis des annĂ©es (NDT : cela dĂ©signe la news originale sur le site de GIMP) que Jehan n'a pas Ă©crite presque entiĂšrement ! Merci beaucoup Ă  Alx Sa (alias Nikc ou CmykStudent) d'avoir entamĂ© la rĂ©daction collaborative de la nouvelle !

    Il est clair que nous consolidons jour aprĂšs jour une solide Ă©quipe de contributeurs et cela se voit dans notre processus de publication, avec de plus en plus de retours Ă  chaque version.

    Nous sommes Ă©galement particuliĂšrement heureux et fiers que les 4 projets GSoC que nous avons eus, depuis que nous avons recommencĂ© Ă  souscrire Ă  ce programme de mentorat, aient tous Ă©tĂ© couronnĂ©s de succĂšs et ont fini par ĂȘtre fusionnĂ©s avec la branche principale du code au plus tard six mois aprĂšs la fin du stage.

    Autour de GIMP

    Des nouvelles des miroirs

    Depuis la derniĂšre dĂ©pĂȘche, un nouveau miroir a Ă©tĂ© apportĂ© Ă  GIMP par :

    • Sahil Dhiman, Ă  Nuremberg, en Allemagne, comme projet personnel.

    Cela nous amÚne à un total de 46 miroirs répartis dans le monde.

    Les miroirs sont importants car ils aident le projet en partageant la charge de dizaines de milliers de téléchargements quotidiens. De plus, en disposant de miroirs répartis à travers le monde, nous garantissons que tout le monde puisse avoir un accÚs rapide au téléchargement de GIMP.

    GIMP sous Windows/ARM

    Depuis notre annonce d'une version expĂ©rimentale sur Windows pour l'architecture ARM 64 bits (en anglais), nous avons reçu l'aide de Hernan Martinez, contributeur bien connu du projet MSYS2, qui a hĂ©bergĂ© notre tout premier runner pour l'intĂ©gration continue (CI) pour Windows sur l'architecture Aarch64. Bien que cela n'ait Ă©tĂ© qu'une configuration temporaire (littĂ©ralement une machine de compilation dans le salon de quelqu'un) en attendant une situation plus stable, nous sommes extrĂȘmement reconnaissants envers Hernan qui nous a aidĂ©s Ă  faire notre deuxiĂšme pas sur cette plateforme (la premiĂšre Ă©tape a Ă©tĂ© effectuĂ©e par Jernej, qui a crĂ©Ă© notre premier installateur expĂ©rimental), s'est assurĂ© que notre processus de compilation automatique fonctionne sur cette machine, et plus encore.

    Depuis lors, la situation plus stable est arrivĂ©e : Arm Ltd. eux-mĂȘmes se sont mobilisĂ©s et ont officiellement contribuĂ© trois runners pour notre processus d'intĂ©gration continue dans Gitlab ! Arm Ltd. a Ă©galement sponsorisĂ© un kit de dĂ©veloppement Windows pour l'un de nos dĂ©veloppeurs.

    Bien que nous considĂ©rions toujours cette version comme expĂ©rimentale, en raison du manque de tests et du fait que seuls 2 contributeurs disposent actuellement d'une machine capable de l'exĂ©cuter, le plus gros facteur bloquant a Ă©tĂ© supprimĂ© et nous sommes heureux d'annoncer que notre programme d'installation Windows universel pour GIMP 2.99.18 contient GIMP pour les 3 plates-formes (x86 32 et 64 bits, et maintenant ARM 64 bits) !

    Télécharger GIMP 2.99.18

    Vous trouverez toutes nos versions officielles sur le site officiel de GIMP (gimp.org) :

    • Flatpaks Linux pour x86 et ARM (64 bits)
    • Installateur Windows universel pour x86 (32 et 64 bits) et pour ARM (64 bits)
    • Paquets macOS DMG pour le matĂ©riel Intel
    • Paquets macOS DMG pour le matĂ©riel Apple Silicon

    D'autres paquets réalisés par des tiers devraient évidemment suivre (paquets des distributions Linux ou *BSD, etc.).

    Et ensuite ?

    Alors que nous sommes maintenant entrés dans un gel des fonctionnalités, notre attention s'est déplacée vers la correction des bogues, le nettoyage et la préparation de la premiÚre version candidate 3.0.

    Nous pensons en effet qu'il s'agit de la derniÚre version de développement puisqu'aucune nouvelle fonctionnalité ne sera introduite désormais, du moins au niveau de l'interface utilisateur (l'API est encore en évolution jusqu'à la premiÚre version candidate). Donc, ce que vous voyez maintenant est essentiellement ce que vous devriez obtenir dans GIMP 3.0.0, en termes de fonctionnalités.

    C'est pourquoi nous avons sorti cette version mĂȘme si nous savons qu'elle est assez instable. C'est l'heure des commentaires de derniĂšre minute ! C'est aussi le moment de signaler et de corriger les bogues comme si demain n'existait pas. Nous espĂ©rons pouvoir bientĂŽt livrer une RC1 et elle devrait ĂȘtre aussi dĂ©pourvue de bogue que possible.

    Nous espĂ©rons actuellement pouvoir publier GIMP pour le prochain Libre Graphics Meeting du 9 au 12 mai. Pour ĂȘtre honnĂȘte, ce n’est pas un objectif facile et nous ne sommes donc pas sĂ»rs de pouvoir l’atteindre. Ce qui est sĂ»r, c'est que mĂȘme si nous n'y parvenons pas Ă  temps, cela ne devrait pas arriver trop longtemps aprĂšs. En particulier, nous ne publierons pas simplement parce que nous avons fixĂ© une date limite. Nous voulons offrir la meilleure expĂ©rience possible, ce qui signifie que si nous dĂ©couvrons des bogues bloquants de derniĂšre minute, nous retarderons la sortie jusqu'Ă  ce qu'ils soient corrigĂ©s.

    N'oubliez pas que vous pouvez faire un don et financer personnellement les dĂ©veloppeurs de GIMP, c'est un moyen de donner en retour et d'accĂ©lĂ©rer le dĂ©veloppement de GIMP. L’engagement communautaire permet au projet de se renforcer ! đŸ’ȘđŸ„ł

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    Sortie de LuneOS « Eiskaffee »

    TentĂ©s par un cafĂ© glacĂ© ? LuneOS « Eiskaffee Â» vient de sortir !

    LuneOS est une distribution GNU/Linux pour tĂ©lĂ©phones mobiles et tablettes, hĂ©ritiĂšre de feu webOS. Le projet est portĂ© par l’équipe webOS-Ports, dont le but est de faire revivre webOS sur les matĂ©riels contemporains.

    logo de LuneOS

    Sommaire

    Voici bien longtemps que l’équipe de webOS-ports n’avait fait de nouvelle version de LuneOS. De nombreux changements de fond, de nouveaux tĂ©lĂ©phones et tablettes, des difficultĂ©s techniques mais aussi une Ă©quipe dĂ©veloppement modeste expliquent ce rythme un peu lent qui avance selon le temps libre de chacun.

    Pendant ce temps, des versions de test de LuneOS ont Ă©tĂ© rĂ©guliĂšrement mises Ă  disposition sur Github, dans le dĂ©pĂŽt « luneos-testing ». Cela permet aux personnes intĂ©ressĂ©es d’essayer LuneOS, tout en gardant Ă  l’esprit que ce ne sont que des versions intermĂ©diaires.

    Petits rappels et lexique

    Le projet s’appuie sur Yocto, webOS-OSE, Halium et SHR. Il utilise OpenEmbedded comme environnement de compilation. Cette derniĂšre version de LuneOS se base sur la version « Kirkstone Â» de Yocto. Ces projets ne vous disent rien ? Voici un rapide lexique :

    • OpenEmbedded est un environnement de compilation, qui utilise un ensemble de « recettes Â» pour dĂ©crire les composants Ă  compiler et installer.
    • Yocto est un ensemble de recettes prĂȘtes Ă  l’emploi qu’on peut utiliser pour se construire une distribution Linux personnalisĂ©e. Les recettes mises Ă  disposition vont du noyau Linux Ă  Firefox, et forment un ensemble dĂ©jĂ  assez complet.
    • SHR est un systĂšme d’exploitation GNU/Linux s’appuyant aussi sur Yocto et OpenEmbedded, et orientĂ© tĂ©lĂ©phones. Il a connu son heure de gloire Ă  l’époque des tĂ©lĂ©phones Openmoko comme le FreeRunner. Seule une petite partie est maintenant rĂ©utilisĂ©e pour les besoins de LuneOS.
    • Halium est un ensemble d’utilitaires et d’images Android permettant de faire tourner un Android minimaliste dans un container dĂ©diĂ© sur la distribution hĂŽte. Cela permet d’exploiter les pilotes et firmwares disponibles seulement pour Android, tout en gardant le reste de l’OS sur une pile GNU/Linux/systemd/Wayland classique.
    • webOS-OSE est une distribution Linux maintenue par LG, hĂ©ritiĂšre du code de webOS, et dont LuneOS reprend maintenant beaucoup de composants logiciels.

    À l’exception des blobs utilisĂ©s pour faire tourner les pilotes Android, l’ensemble de la distribution est libre : tout le monde peut, s’il le veut, recompiler sa propre image chez soi.

    Fin du forum webOS Nation et autres tracasseries techniques

    Le forum « webOS Nation », qui regroupe des discussions autour de webOS au sens large (vieilles versions de webOS, mods, LuneOS
) a connu quelques turbulences ces derniĂšres annĂ©es. Devant une fermeture imminente du site web, un nouveau site webOS Archive a Ă©tĂ© mis en place, avec notamment la majoritĂ© des archives des forums de webOS Nation. Un nouveau forum a Ă©tĂ© mis en place, reprenant globalement le style de webOS Nation.

    Sans avoir une activitĂ© folle, la communautĂ© autour de webOS reste prĂ©sente, notamment grĂące Ă  la prĂ©sence aujourd’hui de webOS sur les tĂ©lĂ©viseurs.

    Mort du « builder » dĂ©diĂ© Ă  LuneOS

    Suite Ă  plusieurs avaries, le builder « Jenkins » a dĂ» prendre une retraite bien mĂ©ritĂ©e. Malheureusement cela implique pour l’équipe de webOS-ports de compiler les diffĂ©rentes images de LuneOS chez soi, ce qui n’est pas trĂšs pratique (sans ĂȘtre une catastrophe). Sur une machine raisonnablement puissante, la crĂ©ation d’une image de LuneOS depuis zĂ©ro demande plusieurs heures, il faut donc parfois s’armer de patience. Heureusement Yocto permet de mutualiser les rĂ©sultats de compilation pour les architectures semblables, ce qui fait gagner beaucoup de temps.

    Les changements majeurs

    Depuis la derniĂšre version publique de LuneOS, beaucoup de changements de fond ont eu lieu. On retrouve entre autres:

    Passage de Qt 5 Ă  Qt 6

    LuneOS utilise maintenant Qt 6.5.2, l’une des derniùres disponibles.

    Utilisation du compositeur Wayland de webOS OSE

    Le compositeur Wayland propre Ă  LuneOS luna-next a Ă©tĂ© abandonnĂ©, au profit du compositeur Wayland de webOS OSE surface-manager. Cependant la partie graphique (codĂ©e en QML) a Ă©tĂ© conservĂ©e, et l’expĂ©rience utilisateur reste donc trĂšs similaire.
    Cela permet de se concentrer sur la partie GUI du compositeur, tout en bĂ©nĂ©ficiant des mises Ă  jour venant de OSE relatives au cƓur mĂȘme du compositeur.

    Changement de moteur Chromium

    Les apps webOS utilisant intensivement HTML/Javascript/CSS, l’affichage nĂ©cessite un moteur web bien Ă  jour et optimisĂ©. Jusqu’à la derniĂšre version, LuneOS utilisait QtWebEngine, fourni par Qt, pour faire tourner les applications.
    Cependant webOS-OSE fournit son propre moteur basé sur chromium, indépendant de Qt et optimisé pour une utilisation embarquée. LuneOS a donc également migré vers cette nouvelle infrastructure logicielle, adoptant ce composant WebAppManager.

    Migration générale vers les composants de webOS-OSE

    Plus généralement, les composants hérités de feu Open WebOS ont été remplacés par leur équivalent dans webOS-OSE, plus récents et encore maintenus par LG. Pour cette version de LuneOS, la version 2.23.0 de webOS-OSE est utilisée comme base.
    Cette migration inclut notamment l’utilisation des « Enhanced ACG », un modĂšle de sĂ©curitĂ© plus efficace utilisĂ© pour la communication entre les services de webOS et les apps.

    Ces changements, qui pour la plupart ne sont pas visibles Ă  l’utilisation, apportent de multiples bĂ©nĂ©fices pour LuneOS :

    • une rĂ©utilisation plus large du code de webOS-OSE (maintenu par LG), ce qui implique moins de maintenance cĂŽtĂ© webOS-ports
    • meilleure stabilitĂ© des composants, qui sont utilisĂ©s depuis des annĂ©es dans les tĂ©lĂ©viseurs et appareils LG
    • la rĂ©tro-compatibilitĂ© a tout de mĂȘme pu ĂȘtre assurĂ©e pour les vieilles apps webOS, grĂące Ă  des modifications mineures dans certains composants
    • plus de facilitĂ© pour mettre Ă  jour les composants venant de webOS-OSE

    TĂ©lĂ©phones et tablettes: vers plus de Linux « mainline »

    Dans le domaine des distributions Linux pour tĂ©lĂ©phones et tablettes, on parle de noyau « mainline » pour dĂ©signer l’utilisation directe du code source venant du noyau Linux, par opposition Ă  l’utilisation d’un code source dĂ©rivĂ© et proposĂ© par un constructeur. Ce dernier est souvent proposĂ© dans une vieille version, avec une maintenance trĂšs limitĂ©e dans le temps.

    Cependant, utiliser un noyau « mainline » est Ă  double tranchant : d’un cĂŽtĂ©, on bĂ©nĂ©ficie des derniĂšres avancĂ©es du noyau, et des derniĂšres versions des pilotes libres. Mais de l’autre, cela signifie devoir se passer des pilotes proposĂ©s par le constructeur (pour le son, le GPS, le modem
), qui souvent n’ont jamais Ă©tĂ© proposĂ©s Ă  l’inclusion dans le code source principal de Linux.

    Au final, dans le cas de LuneOS, trois voies se dessinent lorsqu’il s’agit de faire tourner l’OS sur un tĂ©lĂ©phone ou une tablette :

    1. Le constructeur remonte ses changements dans le noyau Linux, et s’appuie sur un dĂ©veloppement open-source: Pine64 et Purism sont deux exemples rĂ©cents de cette approche. C’est le cas idĂ©al pour LuneOS, oĂč des pilotes open-source bien intĂ©grĂ©s peuvent ĂȘtre utilisĂ©es pour faire fonctionner les composants matĂ©riels.
    2. Le constructeur ne propose qu’une version Android de ses pilotes et du noyau; ce dernier reste figĂ© dans une mĂȘme version, relativement rĂ©cente, avec une maintenance minimale. LuneOS va alors utiliser Halium pour profiter des pilotes faits pour Android, tout en gardant le reste du systĂšme sur une pile logicielle « systemd/glibc » classique. Cette situation reste trĂšs prĂ©sente, car l’immense majoritĂ© des tĂ©lĂ©phones et tablettes du marchĂ© tournent sur Android.
    3. Le constructeur propose une vieille version du noyau, non maintenue, et dont les limitations deviennent problĂ©matiques pour LuneOS. Dans ce cas, LuneOS va tenter d’utiliser un noyau plus rĂ©cent, mais qui a un support partiel du matĂ©riel. Cette stratĂ©gie a souvent un rĂ©sultat trĂšs mitigĂ©, avec de gros manques fonctionnels. En gros, c’est la tentative de la derniĂšre chance avant l’abandon du support de ce matĂ©riel.

    Le matériel Pine64

    Une tablette PineTab2 avec LuneOS

    Comme Ă©voquĂ© plus haut, Pine64 cultive ses liens avec la communautĂ© open-source, et incite celle-ci Ă  proposer leurs OS sur leur matĂ©riel. On retrouve ainsi de nombreux OS comme PostmarketOS, Plasma Mobile ou encore Ubuntu Touch. LuneOS a pris le train en marche trĂšs tĂŽt, et peut aujourd’hui s’installer sur le Pinephone, le Pinephone Pro ainsi que sur la tablette PineTab 2.

    Pour le Pinephone et le Pinephone Pro, LuneOS nĂ©cessite maintenant l’installation prĂ©alable de Tow-boot sur le tĂ©lĂ©phone. Ce dernier est un dĂ©rivĂ© de U-Boot, qui vise Ă  standardiser et faciliter le dĂ©marrage des OS sur du matĂ©riel embarquĂ©.

    Comme ce matériel tourne avec une version trÚs récente du noyau Linux, il est possible pour LuneOS de lancer Waydroid; cependant cette fonctionnalité est jeune et nécessite encore beaucoup de travail.

    Le matériel Android

    LuneOS peut s’installer sur de nombreux autres tĂ©lĂ©phones (et sur la vĂ©nĂ©rable tablette HP Touchpad), grĂące Ă  l’utilisation de Halium (ici en version 9.0).

    Cependant, mĂȘme s’il n’est pas prĂ©vu d’abandonner les tĂ©lĂ©phones et tablettes Android, les efforts se concentrent de plus en plus sur le matĂ©riel pour lequel un noyau « mainline » existe.

    Plans pour la prochaine version

    Continuer la migration vers l’infrastructure de webOS-OSE

    Mettre Ă  jour les composants vers la derniĂšre version de webOS-OSE, et finir la migration:

    • mettre Ă  jour le moteur web vers Chromium 108 (tout juste sorti du four chez LG)
    • re-baser l’infrastructure audio et multimĂ©dia de LuneOS sur les composants fournis par webOS-OSE
    • travailler Ă©galement sur le support des camĂ©ras

    Continuer le travail sur le matériel supporté

    • Avoir un noyau « mainline » fonctionnel pour Tenderloin, Hammerhead, Mido and Tissot.
    • Fournir une image GSI unique pour les tĂ©lĂ©phones Android, permettant de faciliter grandement le support d’autres tĂ©lĂ©phones

    ComplĂ©ter l’espace applicatif

    • AmĂ©liorer ou ajouter des apps de base comme Camera, Flashlight, Audio Player ou Video Player, et amĂ©liorer les composants QML.
    • Essayer de profiter du travail fait par la communautĂ© sur les TVs LG « homebrew » : webOS Brew

    Envie d’essayer ?

    Pour le tĂ©lĂ©chargement et l’installation, c’est par ici. Il existe notamment une image pour Ă©mulateur x86-64, utilisable directement dans VirtualBox.

    L’équipe webOS-ports est prĂ©sente sur IRC (Libera:#webos-ports) ou encore Telegram.

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    L’auteur de Nginx enfourche le proprio

    Maxim Dounin, l'un des principaux dĂ©veloppeurs de NGINX (il est Nginx disent mĂȘme certains) se barre et crĂ©e un fork.

    Nginx est l'un des principaux serveurs web, voire le plus utilisĂ© mais ça dĂ©pend des statistiques. Il est rĂ©putĂ© pour sa vitesse, sa lĂ©gĂšretĂ© et sa soliditĂ©. La version libre est au coeur d'Nginx, aussi costaud, rapide et sĂ©curisĂ©e que la version avec quelques extensions propriĂ©taire. Malheureusement, ça pourrait ne plus ĂȘtre le cas :

    En 2019, F5 Networks a rachetĂ© la sociĂ©tĂ© derriĂšre Nginx. En 2022, F5 a fermĂ© les bureaux de Moscou, signant un accord avec Maxim Dounin qui continuait bĂ©nĂ©volement Ă  travailler sur Nginx. Ayant quittĂ© la sociĂ©tĂ©, il veillait sur cette piĂšce essentielle du web et du libre. Or en 2024, la nouvelle direction d'F5 n'entend que pouic Ă  la technique et se focalise sur le marchĂ©. Elle s'est mĂȘlĂ©e des questions de sĂ©curitĂ©, prĂ©fĂ©rant une version libre moins robuste afin de vendre plus de prestations — d'aprĂšs Maxim Dounin.

    Le 14 février, il en a eu marre et a lancé le projet Freenginx pour garantir un développement sans interférences marketing.

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    Archiver ses vidĂ©os : retour d’expĂ©rience.

    PrĂ©ambule : ma vie (et peut-ĂȘtre aussi la vĂŽtre)

    Comme probablement beaucoup d’entre vous, j’ai des milliers de photos et vidĂ©os accumulĂ©es au cours des 20 derniĂšres annĂ©es. C’est trĂšs pratique de pouvoir stocker cela sur un seul disque dur. Mais cela pose trois problĂšmes majeurs :

    1. la pĂ©rennitĂ© du support ;
    2. le classement des fichiers pour pouvoir en retrouver un en particulier dans
 trùs longtemps.
    3. la possibilitĂ© de lire des fichiers dans plusieurs annĂ©es (je pense Ă  des fichiers Publisher 2.0 que je ne suis plus parvenu Ă  lire par la suite – et non : les versions ultĂ©rieures Ă  Publisher 2.0 ne lisent pas ces fichiers.

    Ce texte s’adresse Ă  toute personne qui se pose trois questions :

    1. Pourrai-je visionner mes fichiers vidĂ©os dans 30 ans pour les montrer Ă  mes petits-enfants ?
    2. Comment organiser/classer mes fichiers vidĂ©os pour les retrouver rapidement ?
    3. Comment rĂ©encoder mes fichiers vidĂ©os pour limiter la place occupĂ©e (ou, dit autrement : quel format utiliser) ?

    AprĂšs avoir lu cette dĂ©pĂȘche, je vous recommande trĂšs fortement de vous reporter aux commentaires qui suivent car vous y trouverez probablement des prĂ©cisions, liens, corrections ou suggestions qui l’enrichissent.

    • Pour le point 1., aucun support n’étant inaltĂ©rable/incassable, la rĂšgle tient en une phrase : « sauvegarder sur plusieurs supports (pour parer une Ă©ventuelle dĂ©faillance), dans diffĂ©rents endroits (en cas d’incendie, de vol, d’inondation
) et si possible en chiffrant ses disques (pour protĂ©ger votre vie privĂ©e en cas de vol : c’est incroyablement simple sous linux)
    • Pour le point 2., j’avais rĂ©digĂ© un document il y a fort fort longtemps oĂč j’expliquais que le seul classement pĂ©renne Ă©tait le classement chronologique (je vous laisse vous reporter au document pour comprendre pourquoi l’utilisation de logiciels propriĂ©taires est Ă  proscrire). Pour rĂ©sumer, je crĂ©e un dossier par annĂ©e (2023) dans lequel il y a douze sous-dossiers (2023_01, 2023_02 etc.) et dans chacun d’eux, je crĂ©e un dossier par jour avec la date et le lieu (par exemple, 2023_06_25_saint_denis_la_reunion indique immĂ©diatement oĂč et quand ont Ă©tĂ© prises les photos et les vidĂ©os Ă  l’intĂ©rieur de ce dossier). Les photos sont renommĂ©es (et retournĂ©es si nĂ©cessaire) automatiquement avec l’instruction jhead -autorot -nf%Y_%m_%d__%H_%M_%S_ *.jpg. Les vidĂ©os sont renommĂ©es manuellement sous la forme 2023_06_25__video_02_christophe_et_philippe_en_velo.mov 1
    • Pour le point 3., le format JPG Ă©tant ouvert, la lisibilitĂ© des photos est garantie dans le temps. Pour les vidĂ©os, c’est un peu plus compliquĂ© puisqu’en gĂ©nĂ©ral, trois formats interviennent :
      • le codec vidĂ©o pour l’image (comme h264, h265, av1, mjpeg
) ;
      • le codec audio pour le son (comme mp3)
      • le format de conteneur (comme avi, mp4, mts
)

    C’est lĂ  oĂč on en revient Ă  l’histoire de ma vie.


    1. note : je n’ai jamais trouvĂ© comment rĂ©cupĂ©rer les mĂ©tadonnĂ©es des vidĂ©os pour les utiliser dans le nom du fichier, comme je le fais avec jhead. â†©

      Sommaire

      I Il Ă©tait une fois MA vie !

      AprĂšs plus de 20 ans de stockage, mon disque dur de 1 To frisait les 90 % de remplissage. Alors, oui, 1 To, c’est trĂšs commun aujourd’hui : il me suffisait d’acheter un disque de 4 To et le problĂšme Ă©tait rĂ©glĂ©.

      Oui
 mais non. Je n’aime pas occuper de la place. Je pense que c’est une mauvaise habitude que d’avoir des tĂ©raoctets disponibles ou des gigaoctets sur une carte SD pour son smartphone que l’on utilise sans se poser de questions en ayant l’impression d’un stockage illimitĂ©. Car un jour, cela nous revient dans les dents (carte SD/disque dur qui plante sans sauvegarde, rĂ©installation de tout le systĂšme, sauvegarde de ses milliers de photos que l’on se dĂ©cide - un jour - de ranger dans un dossier A_RANGER1 puis A_RANGER2 puis A_RANGER3, etc. puis on abandonne).

      En ayant un espace de stockage limité, on doit apprendre à le gérer.

      Les plus anciens se souviennent peut-ĂȘtre des magnĂ©toscopes : on achĂšte des cassettes, on enregistre des films en se disant « je le regarderai un jour Â» et on se retrouve avec des centaines de cassettes qui prennent la poussiĂšre. Ben c’est pareil avec les disques durs : on a des tĂ©raoctets en pagaille et on se dit : « je garde, on ne sait jamais. Et un jour (qui n’arrivera jamais), je ferai le tri ! Â»
      J’en reviens donc Ă  mon disque dur quasi plein. Je fais une recherche sur mes fichiers vidĂ©os et regarde le dĂ©bit binaire (bitrate par la suite) : 40 000 kb/s soit environ 5 Mo/s pour des vidĂ©os FullHD et jusqu’à 100 Mb/s (12 Mo/s) pour des vidĂ©os 4k (Ă©videmment, cela dĂ©pend de l’appareil Ă  l’origine de la vidĂ©o). Voici les diffĂ©rents bitrate que j’ai pu rencontrer :
      ‱ fichier mp4 4K drone : 100 Mb/s ;
      ‱ fichier mp4 4K go pro : 60 Mb/s
      ‱ fichier mov FullHD : environ 16Mb/s
      ‱ ficher avi 640*480 : environ 15 MB/ (mjpeg et format son araw)
      ‱ fichier avi 320*240 : entre 1 et 2,5 Mb/s

      Loin d’ĂȘtre un expert dans la compression vidĂ©o, le poids des fichiers m’interpelle quand mĂȘme. En effet, un site de tĂ©lĂ©chargement de films - que je n’ai jamais frĂ©quentĂ© car c’est illĂ©gal - a pour objectif d’optimiser le ratio qualitĂ©/poids et donc d’offrir une bonne qualitĂ© visuelle pour un poids rĂ©duit. Ainsi, un film en FullHD de 90 min a un poids de 1400 Mo soit un bitrate d’environ 2 Mb/s (250 ko/s avec le codec H264). Un film en 4K de 90 min a un poids de 4 Go soit un bitrate d’environ 4Mb (500 ko/s avec le codec H265). Et il paraĂźt – je ne le sais pas directement car je n’ai jamais frĂ©quentĂ© ce site dont je ne connais mĂȘme pas l’existence – que la qualitĂ© des films sur le site en question est bonne, visuellement parlant s’entend.

      Il était donc temps de se mettre au travail et de réencoder mes vidéos personnelles.

      L’objectif de ce document est donc triple (et permettra de rĂ©pondre aux questions 1. et 3. que s’est posĂ© le lecteur ou la lectrice dans le prĂ©ambule :

      • rĂ© encoder ses vidĂ©os automatiquement via un script bash (en utilisant le logiciel libre ffmpeg ) sans perte de qualitĂ© visible  ;
      • rĂ©duire le poids des fichiers de façon notable (par notable, j’entends ici une rĂ©duction d’au moins 20 %, ce qui est totalement subjectif, mais j’assume) ;
      • s’assurer de la pĂ©rennitĂ© de ses vidĂ©os (i.e. ĂȘtre capable de les visionner dans 20 ans) ;

      II Mon environnement

      • Le matĂ©riel : Lenovo V45 (payĂ© 300 â‚Ź environ avec un AMD A4-9125 radeon R3, 8Go de mĂ©moire vive et un SSD Samsung de 1To, le tout sous kubuntu 22,04).
      • Les logiciels : ffmpeg version 4.4.2, vlc, krename (pour renommer ses fichiers par lot), kfind pour retrouver des fichiers avec des extensions prĂ©cises (je ne maĂźtrise pas du tout l’outil en ligne de commande find), avidemux pour faire du montage vidĂ©o basique (couper quelques minutes d’une vidĂ©o par exemple), dolphin pour naviguer dans les fichiers et, surtout, indicator-cpufreq (qui permet de rĂ©duire la frĂ©quence du processeur et Ă©viter que le ventilateur ne tourne en permanence).

      III Les choix techniques

      Je ne devais utiliser que des logiciels libres et des formats ouverts. Pour les logiciels : mon choix s’est portĂ© sur ffmpeg pour l’encodage car c’est LA rĂ©fĂ©rence pour la conversion de vidĂ©os, mĂȘme si l’usage de la ligne de commande peut rebuter cetains (mais vous verrez par la suite que les scripts simplifient grandement la vie). Pour les formats :

      • MP3 pour l’audio : il n’est plus protĂ©gĂ© par un brevet depuis 2017 et me convenait parfaitement, en choisissant un dĂ©bit de 250kb/s (ce qui est sĂ»rement excessif mais la place occupĂ©e par le son dans une vidĂ©o est faible par rapport Ă  la vidĂ©o). Je sais qu’il y a vorbis mais le mp3 me semble plus « universel Â», notamment si l’on regarde la vidĂ©o sur un tĂ©lĂ©viseur
      • MKV pour le conteneur : c’est un format ouvert et qui est lu sur tous les tĂ©lĂ©viseurs sur lesquels j’ai pu le tester.
      • H265 pour le format vidĂ©o : c’est un format sorti en 2013 soumis Ă  brevet mais il est possible d’utiliser une bibliothĂšque libre (x265) pour effectuer l’encodage (c’est cette bibliothĂšque qu’utilise ffmpeg). LĂ  encore, lorsque j’ai testĂ© des vidĂ©os encodĂ©es en h265 sur diffĂ©rents tĂ©lĂ©viseurs pas trop vieux, je n’ai jamais eu de problĂšme. Sachez qu’il existe le format AV1, plus rĂ©cent, plus efficace en termes de compression, libre et qui rĂ©pond Ă  mes besoins. Mais deux Ă©lĂ©ments m’ont fait renoncer Ă  l’utiliser :
        • l’encodage (avec ma machine) est extrĂȘmement lent (j’ai abandonnĂ© l’encodage de 30 secondes de vidĂ©o quand, aprĂšs une heure, il en Ă©tait toujours Ă  la premiĂšre seconde !) ;
        • il n’est pas encore gĂ©nĂ©ralisĂ© : peu de tĂ©lĂ©viseurs peuvent lire ce format (si vous en connaissez, je suis preneur). Il est fort probable que dans une dizaine d’annĂ©es, je rĂ©encoderai mes vidĂ©os en AV1, mais laissons cela pour plus tard.

      J’ai Ă©galement choisi d’encoder mes vidĂ©os en deux passes car cela me permet de dĂ©cider du dĂ©bit binaire (et donc de la taille du fichier finale) tout en ayant une meilleure qualitĂ© qu’en une passe.
      J’ai utilisĂ© le programme indicator-cpufreq qui me permet de rĂ©duire au minimum la frĂ©quence de mon processeur (ici 1,2 Gh) afin d’éviter que le ventilateur ne tourne sans arrĂȘt (Ă  noter qu’une mise en veille repasse la frĂ©quence au maximum et il n’est plus possible de la rĂ©duire, sauf Ă  redĂ©marrer l’ordinateur). Avec une frĂ©quence rĂ©duite au minimum, le ventilateur ne se dĂ©clenche que quelques secondes toutes les minutes et le processeur ne dĂ©passe pas les 50°C (c’est hardinfo qui me le dit).

      IV Les problĂšmes rencontrĂ©s et les contraintes (spoiler : il faut du temps !)

      • L’encodage en deux passes permet d’obtenir une meilleure qualitĂ© visuelle (de ce que j’ai compris) mais au prix d’un temps de calcul doublĂ©. Ainsi, une vidĂ©o d’une minute (en FullHD) a nĂ©cessitĂ© environ 100 minutes d’encodage pour obtenir le fichier final. Autant vous dire que mon ordinateur a tournĂ© pendant environ 5 mois prĂšs de 20 heures par jour en moyenne. En revanche, j’ai dĂ©couvert comment arrĂȘter un processus (kill - STOP numero_pid_util) lorsque j’avais besoin de retrouver toute la puissance du processeur et comment le reprendre plus tard (kill - CONT numero_pid_util). Par ailleurs, je n’ai pas trouvĂ© comment utiliser la carte graphique pour le rĂ©encodage, car il paraĂźt que c’est plus rapide

      • Je ne connais pas l’instruction ou l’option (si elle existe) de ffmpeg qui permet de conserver les mĂ©tadonnĂ©es des vidĂ©os. Ainsi, la conversion effectuĂ©e avec les scripts ci-dessous supprime toutes les mĂ©tadonnĂ©es (pourtant, cela semble possible)
      • Je n’ai pas trouvĂ©, malgrĂ© mes recherches, comment reprendre la premiĂšre passe d’un encodage aprĂšs une coupure ou un bug (ffmpeg gĂ©nĂšre un fichier log durant la premiĂšre passe, fichier qu’il devrait ĂȘtre possible de rĂ©utiliser afin de reprendre lĂ  oĂč il s’est arrĂȘtĂ©). Il m’a donc fallu, parfois, reprendre l’encodage d’une vidĂ©o Ă  zĂ©ro.
      • La procĂ©dure avant encodage demande de l’organisation :
        • Rechercher toutes ses vidĂ©os est relativement aisĂ© et rapide : kfind permet d’effectuer une recherche sur de multiples formats. Ensuite, un copier-coller sur un autre disque dur permet de les isoler.
        • Il est nĂ©cessaire de connaĂźtre le bitrate de chacune d’elle. Une recherche Internet et hop, le script qui va bien (voir la partie sur les scripts) gĂ©nĂšre un fichier CSV pour nous faciliter le travail.
        • Il faut ensuite regrouper les vidĂ©os par dĂ©bit et dĂ©finition : ainsi, une vidĂ©o 640*480 de 10 Mb/s ne pouvait pas ĂȘtre dans le mĂȘme rĂ©pertoire qu’une vidĂ©o en 320*240 de 5 Mb/s Ă©galement puisque le bitrate final n’était pas le mĂȘme. LĂ , pas de secret, il faut le faire manuellement. Mais rassurez-vous, bien souvent, les vidĂ©os d’une mĂȘme pĂ©riode ont toute le mĂȘme bitrate.
        • L’étape suivante a consistĂ© Ă  choisir le dĂ©bit final des vidĂ©os suivant leur dĂ©finition de façon Ă  ce que la vidĂ©o finale subisse une compression pas ou peu visible Ă  l’Ɠil par rapport Ă  l’original (ce qui est trĂšs subjectif). J’ai donc choisi (en partant des dĂ©bits de YiFY et un peu au doigt mouillĂ©) :
          • 10 Mb/s pour de la 4K (portĂ© trĂšs rarement Ă  12 Mb/s si la vidĂ©o comportait beaucoup de mouvements) ;
          • 4 Mb/s pour de la FullHD ;
          • environ 2 Mb/s pour de la 640*480
          • 1 Mb/s pour de la 320*240
      • Un bug est apparu lors de la conversion des fichiers MJPEG directement en H265 : les couleurs finales Ă©taient complĂštement diffĂ©rentes des originales. Je ne suis pas le seul Ă  avoir subi ce qui semble ĂȘtre un bug. Au final, j’ai contournĂ© ce dĂ©sagrĂ©ment en convertissant d’abord ces fichiers en xvid avec un gros bitrate pour limiter la perte de qualitĂ© (opĂ©ration trĂšs rapide) puis les xvid en H265, ce qui a rĂ©glĂ© le problĂšme.
      • J’imagine que, comme beaucoup d’entre nous, je souhaite limiter mon impact environnemental. N’ayant pas de panneaux photovoltaĂŻques, mon empreinte carbone est probablement Ă©levĂ©e car j’ai Ă©tĂ© contraint de laisser tourner mon ordinateur jour et nuit en consommant de l’électricitĂ© pas toujours verte. En contrepartie, j’économise l’achat d’un nouveau disque dur. Cela me permet de me donner bonne conscience.

      V Les scripts utilisés

      Ces scripts (qui fonctionnent sous Linux. Pour Windows, il faudra adapter
) ont Ă©tĂ© Ă©crits Ă  partir de ce que j’ai trouvĂ© sur Internet car ma maĂźtrise de ce genre d’outils est trĂšs fragile voire inexistante (j’ai donc pas mal bidouillĂ© et ils peuvent sĂ»rement ĂȘtre optimisĂ©s). Je vous dirais volontiers qu’ils sont sous licence libre ou dans le domaine public mais n’ayant pas notĂ© mes sources, je les livre ci-dessous sans aucune garantie de quoi que ce soit (la seule chose que je peux garantir, c’est que j’ai fait pas mal de modifications par rapport aux scripts originaux).
      Je vous rappelle que pour utiliser ces scripts, vous devez faire un copier-coller du script dans un fichier texte (en utilisant kate par exemple), l’enregistrer puis le rendre exĂ©cutable. Ensuite, vous placez ce script dans le rĂ©pertoire de vos vidĂ©os, et, dans une console, vous tapez ./nom_du_script
      Je pense avoir mis suffisamment de commentaires pour comprendre ce que fait chaque script. Si cela n’était pas le cas, signalez les erreurs ou les suggestions dans les commentaires.
      Voici un rĂ©sumĂ© pour chacun d’eux :

      1. convertion_par_lot_videos_en_265 : c’est le script que j’ai le plus utilisĂ© pour convertir des vidĂ©os en H265 en choisissant une ou deux passes et le bitrate.
      2. convertion_par_lot_videos_en_265_une_passe_crf : convertir en une seule passe en choisissant la qualitĂ© voulue
      3. convertion_par_lot_videos_en_xvid : convertir des vidĂ©os au format XVID, lorsque la conversion des MJPEG vers H265 pose problĂšme
      4. convertion_vers_mkv_par_lot : convertir tous les formats de conteneur en MKV (j’ai eu parfois des problĂšmes avec certaines extensions, le passage en MKV rĂ©glait le problĂšme) ;
      5. convertion_videos_en_son_par_lot : ne garder que le son (pour des vidĂ©os youtube que l’on souhaite uniquement Ă©couter par exemple) ;
      6. convertir_son_en_mp3_garder_video : rĂ©econde uniquement le son en MP3, ne touche pas la vidĂ©o
      7. extraire_image_precise_d_une_video : permet d’extraire une image prĂ©cise (par exemple la 123) d’une ou plusieurs vidĂ©os. Ce script m’a permis de comparer l’image d’origine et l’image rĂ©encodĂ©e. J’utilisais ensuite Gimp pour visualiser les diffĂ©rences entre les deux images.
      8. recuperer_bitrate_video_par_lot : rĂ©cupĂšre tous les bitrates des vidĂ©os d’un mĂȘme rĂ©pertoire et l’exporte dans un fichier CSV (donnĂ©es sĂ©parĂ©es par une espace) ;
      9. recuperer_toutes_infos_video_par_lot : exporte dans un fichier csv les dimensions de l’image, le fps etc. mais pas le bitrate (je n’ai pas trouvĂ© comment fusionner ce script avec le prĂ©cĂ©dent)
      10. stabiliser_video_par_lot_en_testant_les_10_qualites : script pour stabiliser une vidĂ©o avec une image « secouĂ©e Â» en testant les 10 qualitĂ©s possibles automatiquement. Vous pouvez faire des tests, chez moi, ce n’était pas probant. Le script est Ă  revoir probablement.
      11. stabiliser_video_par_lot_version : idem que ci-dessus mais vous choisissez le paramĂštre de la stabilisation.
      12. creer_video_cote_a_cote_par_lot : pour comparer deux vidĂ©os en en crĂ©ant une nouvelle avec les deux cĂŽte Ă  cĂŽte (je l’utilise pour comparer la vidĂ©o d’origine et la vidĂ©o stabilisĂ©e).
      13. supprimer_bande_son_video : ne conserve que la vidĂ©o, supprime le son (pour des vidĂ©os oĂč le son ne prĂ©sente aucun intĂ©rĂȘt). Et c’est parti !

      convertion_par_lot_videos_en_265

      #/bin/bash
      # conversion par lot de fichier video au format H265 avec audio en mp3 qualité 256k
      # nice -19 signifie que le programme aura la priorité la plus faible, ce qui ne devrait pas beaucoup ralentir l'exécution des autres programmes (en théorie tout au moins...)
      # si vous souhaitez interrompre le programme pour avoir accÚs à tout le processeur, tapez l'instruction top puis identifiez le PID UTIL des processeurs ffmpeg concernés puis tapez kill - STOP numero_pid_util. Pour relancer le processus, tapez kill - CONT numero_pid_util
      echo "Ce script va rĂ©encoder vos vidĂ©os (MKV MP4 MTS AVI MOV WEBM FLV MPG MPEG WMV 3GP RM ASX VOB F4V MKS M4V OGV M2V MPV TS M2TS AVC HEVC M1V M2V MPV) en H265, le son en MP3 256k et au format de conteneur MKV en 1 ou 2 passes. Vous allez pouvoir choisir le bitrate d'encodage pour la vidĂ©o, le codec et le nombre de passe. Les extensions des vidĂ©os peuvent ĂȘtre en minuscules ou majuscules mais pas un mĂ©lange des deux. Les fichiers originaux seront dĂ©placĂ©s dans le dossier originaux et les fichiers convertis dans le dossier convertis_x265"
      echo -n "Entrez le bitrate -sans espace - que vous souhaitez utiliser : (4000 recommandé pour de la video FullHD, 10000 pour de la 4K) "
      read bitrate
      # les lignes (rm x265_2pass.log / rm x265_2pass.log.cutree / rm x265_2pass.log.cutree.temp / rm x265_2pass.log.temp) suppriment les fichiers générés lors des deux passes
      # pour conserver l'audio, remplacer -c:a libmp3lame -b:a 256k par -c:a copy
      # pour réduire la qualité audio, remplacer le 256k dans "-c:a libmp3lame -b:a 256k" par un nombre plus petit (par exemple 128k ou 92k)
      echo -n "Souhaitez-vous une passe ou deux passes ? Taper 1 pour une passe (plus rapide mais de moins bonne qualité) ou 2 pour deux passes (plus lent mais la vidéo finale est de meilleure qualité) :  "
      read passe
      if [ "$passe" = "1" ] ; then
      mkdir originaux
      # crĂ©e un rĂ©pertoire oĂč seront dĂ©placĂ©s les fichiers originaux aprĂšs conversion
      mkdir convertis_x265
      #crĂ©e un rĂ©pertoire oĂč seront dĂ©placĂ©s les fichiers convertis
          for i in *.mkv *.MKV *.mp4 *.MP4 *.mts *.MTS *.avi *.AVI *.mov *.MOV *.webm *.WEBM *.flv *.FLV *.mpg *.MPG *.mpeg *.MPEG *.wmv *.WMV *.3gp *.3GP *.rm *.RM *.asx *.ASX *.vob *.VOB *.f4v *.F4V *.mks *.MKS *.m4v *.M4V *.ogv *.OGV *.m2v *.M2V *.mpv *.MPV *.ts *.TS *.m2ts *.M2TS *.avc *.AVC *.hevc *.HEVC *.m1v *.M1V *.m2v *.M2V *.mpv *.MPV ; do
          nice -19 ffmpeg -i "$i" -c:v "libx265" -b:v "${bitrate}k" -"x265"-params pass=1 -c:a libmp3lame -b:a 256k "$i.mkv"
          mv "$i.mkv" ./convertis_x265
          #déplace les fichiers convertis
          mv "$i" ./originaux
          #déplace les fichiers originaux
          done
      elif [ "$passe" = "2" ]; then
      mkdir originaux
      # crĂ©e un rĂ©pertoire oĂč seront dĂ©placĂ©s les fichiers originaux aprĂšs conversion
      mkdir convertis_x265
      #crĂ©e un rĂ©pertoire oĂč seront dĂ©placĂ©s les fichiers convertis
          for i in *.mkv *.MKV *.mp4 *.MP4 *.mts *.MTS *.avi *.AVI *.mov *.MOV *.webm *.WEBM *.flv *.FLV *.mpg *.MPG *.mpeg *.MPEG *.wmv *.WMV *.3gp *.3GP *.rm *.RM *.asx *.ASX *.vob *.VOB *.f4v *.F4V *.mks *.MKS *.m4v *.M4V *.ogv *.OGV *.m2v *.M2V *.mpv *.MPV *.ts *.TS *.m2ts *.M2TS *.avc *.AVC *.hevc *.HEVC *.m1v *.M1V *.m2v *.M2V *.mpv *.MPV ; do
          nice -19 ffmpeg -y -i "$i" -c:v "libx265" -b:v "${bitrate}k" -"x265"-params pass=1 -an -f null /dev/null && \
          #premiĂšre passe
          nice -19 ffmpeg -i "$i" -c:v "libx265" -b:v "${bitrate}k" -"x265"-params pass=2 -c:a libmp3lame -b:a 256k "$i.mkv"
          mv "$i.mkv" ./convertis_x265
          #déplace les fichiers convertis
          mv "$i" ./originaux
          #déplace les fichiers originaux
      #les lignes suivantes suivantes suppriment les fichiers temporaires de la premiĂšre passe en cas d'interruption.
          rm x265_2pass.log
          rm x265_2pass.log.cutree
          rm x265_2pass.log.cutree.temp
          rm x265_2pass.log.temp
          rm x264_2pass.log
          rm x264_2pass.log.cutree
          rm x264_2pass.log.cutree.temp
          rm x264_2pass.log.temp
          done
      else
          echo "Il faut taper 1 ou 2, rien d'autre. Relancez le script !"
      fi
          rm x265_2pass.log
          rm x265_2pass.log.cutree
          rm x265_2pass.log.cutree.temp
          rm x265_2pass.log.temp
          rm x264_2pass.log
          rm x264_2pass.log.cutree
          rm x264_2pass.log.cutree.temp
          rm x264_2pass.log.temp

      convertion_par_lot_videos_en_265_une_passe_crf

      #!/bin/bash
      # conversion par lot de fichier video au format H265 avec audio en mp3 qualité 320k
      # nice -19 signifie que le programme aura la priorité la plus faible, ce qui ne devrait pas beaucoup ralentir l'exécution des autres programmes.
      # si vous souhaitez interrompre le programme pour avoir accÚs à tout le processeur, tapez l'instruction top puis identifiez le PID UTIL des processeurs ffmpeg concernés puis tapez kill - STOP numero_pid_util. Pour relancer le processus, tapez kill - CONT numero_pid_util
      
      echo "Ce script va rĂ©encoder vos vidĂ©os (MKV, MP4, MTS, AVI, MOV, WEBM FLV) en H265, le son en MP3 256k et au format de conteneur MKV en 1 passe. Vous allez pouvoir choisir CRF (constant rate factor) pour la vidĂ©o. Les extensions des vidĂ©os peuvent ĂȘtre en minuscules ou majuscules mais pas un mĂ©lange des deux."
      echo -n "Entrez le CRF que vous souhaitez utiliser : (entre 1 et 51 - 1 pour la meilleure qualité, 51 pour la plus mauvaise) - 28 est recommandé : "
      read crf
      
      echo -n "Entrez la vitesse que vous souhaitez utiliser : (ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow) - votre choix joue sur la vitesse de traitement et la qualité. Superfast sera trÚs rapide mais de moins bonne qualité. medium est le choix recommandé. Votre choix : "
      read speed
      
      # on peut modifier le fichier de sortie en ajoutant un répertoire : "$i.mkv" devient "/home/perso/mon_repertoire/$i.mkv"
      # les lignes (rm x265_2pass.log / rm x265_2pass.log.cutree / rm x265_2pass.log.cutree.temp / rm x265_2pass.log.temp) suppriment les fichiers générés lors des deux passes
      # pour conserver l'audio, remplacer -c:a libmp3lame -b:a 256k par -c:a copy
      # pour réduire la qualité audio, remplacer le 256k dans "-c:a libmp3lame -b:a 256k" par un nombre plus petit (par exemple 128k ou 92k)
      mkdir originaux
      # crĂ©e un rĂ©pertoire oĂč seront dĂ©placĂ©s les fichiers originaux aprĂšs conversion
      mkdir convertis_x265
      #crĂ©e un rĂ©pertoire oĂč seront dĂ©placĂ©s les fichiers convertis
      
          for i in *.mkv *.MKV *.mp4 *.MP4 *.mts *.MTS *.avi *.AVI *.mov *.MOV *.webm *.WEBM *.flv *.FLV *.mpg *.MPG *.mpeg *.MPEG *.wmv *.WMV *.3gp *.3GP *.rm *.RM *.asx *.ASX *.vob *.VOB *.f4v *.F4V *.mks *.MKS *.m4v *.M4V *.ogv *.OGV *.m2v *.M2V *.mpv *.MPV *.ts *.TS *.m2ts *.M2TS *.avc *.AVC *.hevc *.HEVC *.m1v *.M1V *.m2v *.M2V *.mpv *.MPV ;
          do
          nice -19 ffmpeg -i "$i" -c:v libx265 -crf "$crf" -preset "$speed" -c:a libmp3lame -b:a 256k "$i.mkv"
      
          mv "$i.mkv" ./convertis_x265
          #déplace les fichiers convertis
      
          mv "$i" ./originaux
          #déplace les fichiers originaux
          done
      
      #les lignes suivantes suivantes suppriment les fichiers temporaires de la premiĂšre passe en cas d'interruption.
          rm x265_2pass.log
          rm x265_2pass.log.cutree
          rm x265_2pass.log.cutree.temp
          rm x265_2pass.log.temp
          rm x264_2pass.log
          rm x264_2pass.log.cutree
          rm x264_2pass.log.cutree.temp
          rm x264_2pass.log.temp

      convertion_par_lot_videos_en_xvid

      #!/bin/bash
      # ce script balaie tous les fichiers d'un mĂȘme rĂ©pertoire et va convertir les AVI en XVID et conserver le son d'origine
      # nice -19 signifie que le programme aura la priorité la plus faible, ce qui ne devrait pas beaucoup ralentir l'exécution des autres programmes.
      # si vous souhaitez interrompre le programme pour avoir accÚs à tout le processeur, tapez l'instruction top puis identifiez le PID UTIL des processeurs ffmpeg concernés puis tapez kill - STOP numero_pid_util. Pour relancer le processus, tapez kill - CONT numero_pid_util
      
      echo "Ce script va rĂ©encoder vos vidĂ©os AVI en XVID, conserver le son d'origine et au format de conteneur MKV en 2 passes. Les extensions des vidĂ©os (AVI ou avi) peuvent ĂȘtre en minuscules ou majuscules mais pas un mĂ©lange des deux. La convertion directe de MJPEG vers 265 pose des problĂšmes de couleurs. Il faut donc passer par XVID d'abord (voir https://stackoverflow.com/questions/71397605/ffmpeg-mjpeg-h-265-smeared-color-on-output-video-file )"
      # on peut modifier le fichier de sortie en ajoutant un répertoire : "$i.mkv" devient "/home/perso/mon_repertoire/$i.mkv"
      # pour conserver l'audio, remplacer -c:a libmp3lame -b:a 256k par -c:a copy
      # pour réduire la qualité audio, remplacer le 256k dans "-c:a libmp3lame -b:a 256k" par un nombre plus petit (par exemple 128k ou 92k)
      
      mkdir originaux
      # crĂ©e un rĂ©pertoire oĂč seront dĂ©placĂ©s les fichiers originaux aprĂšs conversion
      
      mkdir convertis_xvid
      #crĂ©e un rĂ©pertoire oĂč seront dĂ©placĂ©s les fichiers convertis
      
          for i in *.avi *.AVI ; do
          nice -19 ffmpeg -y -i "$i" -c:v mpeg4 -vtag xvid -b:v 16000k -pass 1 -an -f avi /dev/null
          ffmpeg -i "$i" -c:v mpeg4 -vtag xvid -b:v 16000k -pass 2 -c:a copy "$i.mkv"
      
          mv "$i.mkv" ./convertis_xvid
          #déplace les fichiers convertis
      
          mv "$i" ./originaux
          #déplace les fichiers originaux
      
          done

      convertion_vers_mkv_par_lot

      #!/bin/bash
      # conversion par lot de fichiers vers mkv - mofifier l'extension si nécessaire - supprimer les extensions d'origine avec krename ensuite. Attention, s'il y a déjà des fichiers MKV, ils seront reconvertis en MKV
      
      mkdir originaux
      # crĂ©e un rĂ©pertoire oĂč seront dĂ©placĂ©s les fichiers originaux aprĂšs conversion
      mkdir convertis_mkv
      #crĂ©e un rĂ©pertoire oĂč seront dĂ©placĂ©s les fichiers convertis
      
          for i in *.mkv *.MKV *.mp4 *.MP4 *.mts *.MTS *.avi *.AVI *.mov *.MOV *.webm *.WEBM *.flv *.FLV *.mpg *.MPG *.mpeg *.MPEG *.wmv *.WMV *.3gp *.3GP *.rm *.RM *.asx *.ASX *.vob *.VOB *.f4v *.F4V *.mks *.MKS *.m4v *.M4V *.ogv *.OGV *.m2v *.M2V *.mpv *.MPV *.ts *.TS *.m2ts *.M2TS *.avc *.AVC *.hevc *.HEVC *.m1v *.M1V *.m2v *.M2V *.mpv *.MPV ; do
      
      
      #    autre chose trouvé sur internet avec bug : ffmpeg -flags +genpts -i "$i" -c copy -sn "$i.mkv"
      
      nice -19 ffmpeg -y -i "$i" -c:v copy -c:a copy "$i.mkv"
        mv "$i.mkv" ./convertis_mkv
          #déplace les fichiers convertis
          mv "$i" ./originaux
          #déplace les fichiers originaux
      
      done

      convertion_videos_en_son_par_lot

      #!/bin/bash
      # conversion par lot de fichiers vers mkv - mofifier l'extension si nécessaire - supprimer les extensions d'origine avec krename ensuite. Attention, s'il y a déjà des fichiers MKV, ils seront reconvertis en MKV
      
      mkdir originaux
      # crĂ©e un rĂ©pertoire oĂč seront dĂ©placĂ©s les fichiers originaux aprĂšs conversion
      mkdir convertis_mkv
      #crĂ©e un rĂ©pertoire oĂč seront dĂ©placĂ©s les fichiers convertis
      
          for i in *.mkv *.MKV *.mp4 *.MP4 *.mts *.MTS *.avi *.AVI *.mov *.MOV *.webm *.WEBM *.flv *.FLV *.mpg *.MPG *.mpeg *.MPEG *.wmv *.WMV *.3gp *.3GP *.rm *.RM *.asx *.ASX *.vob *.VOB *.f4v *.F4V *.mks *.MKS *.m4v *.M4V *.ogv *.OGV *.m2v *.M2V *.mpv *.MPV *.ts *.TS *.m2ts *.M2TS *.avc *.AVC *.hevc *.HEVC *.m1v *.M1V *.m2v *.M2V *.mpv *.MPV ; do
      
      
      #    autre chose trouvé sur internet avec bug : ffmpeg -flags +genpts -i "$i" -c copy -sn "$i.mkv"
      
      nice -19 ffmpeg -y -i "$i" -c:v copy -c:a copy "$i.mkv"
        mv "$i.mkv" ./convertis_mkv
          #déplace les fichiers convertis
          mv "$i" ./originaux
          #déplace les fichiers originaux
      
      done

      convertir_son_en_mp3_garder_video

      #!/bin/bash
      echo -n "Ce script va convertir le son des videos en mp3 sans toucher la video et ajouter l'extension .MKV à la fin du fichier. Choisissez la qualité mp3 (256 recommandé) : "
      read bitratemp3
      
      mkdir originaux
      # crĂ©e un rĂ©pertoire oĂč seront dĂ©placĂ©s les fichiers originaux aprĂšs conversion
      mkdir convertis_mp3
      #crĂ©e un rĂ©pertoire oĂč seront dĂ©placĂ©s les fichiers convertis
      
      
      for i in *.mkv *.MKV *.mp4 *.MP4 *.mts *.MTS *.avi *.AVI *.mov *.MOV *.webm *.WEBM *.flv *.FLV *.mpg *.MPG *.mpeg *.MPEG *.wmv *.WMV *.3gp *.3GP *.rm *.RM *.asx *.ASX *.vob *.VOB *.f4v *.F4V *.mks *.MKS *.m4v *.M4V *.ogv *.OGV *.m2v *.M2V *.mpv *.MPV *.ts *.TS *.m2ts *.M2TS *.avc *.AVC *.hevc *.HEVC *.m1v *.M1V *.m2v *.M2V *.mpv *.MPV ; do
      
          nice -19 ffmpeg -i "$i" -c:v copy -c:a libmp3lame -b:a "${bitratemp3}k" "$i.mkv"
      
          mv "$i.mkv" ./convertis_mp3
          #déplace les fichiers convertis
          mv "$i" ./originaux
          #déplace les fichiers originaux
      done

      extraire_image_precise_d_une_video

      #!/bin/bash
      
      
      echo -n "Entrez le numéro de l'image que vous souhaitez extraire (attention, la numérotation commence à 0 donc si vous souhaitez la frame 536, il faut saisir 535) "
      read num_frame
      
      
      for i in *.mkv *.MKV *.mp4 *.MP4 *.mts *.MTS *.avi *.AVI *.mov *.MOV *.webm *.WEBM *.flv *.FLV *.mpg *.MPG *.mpeg *.MPEG *.wmv *.WMV *.3gp *.3GP *.rm *.RM *.asx *.ASX *.vob *.VOB *.f4v *.F4V *.mks *.MKS *.m4v *.M4V *.ogv *.OGV *.m2v *.M2V *.mpv *.MPV *.ts *.TS *.m2ts *.M2TS *.avc *.AVC *.hevc *.HEVC *.m1v *.M1V *.m2v *.M2V *.mpv *.MPV ; do
      
      
      
      nice -19 ffmpeg -i "$i" -vf "select=eq(n\,$num_frame)" -vframes 1 screenshot_frame_"$num_frame"_"$i".png
      
      done

      recuperer_bitrate_video_par_lot

      #!/bin/bash
      
      #recherche le bitrate des videos de façon récursive
      find . \( -iname "*.mkv" -or -iname "*.mov" -or -iname "*.mts" -or -iname "*.mp4" -or -iname "*.mpg" -or -iname "*.mpeg" -or -iname "*.flv" -or -iname "*.avi" -or -iname "*.webm" -or -iname "*.wmv" -or -iname "*.3gp" -or -iname "*.rm" -or -iname "*.asx" -or -iname "*.vob" -or -iname "*.f4v" -or -iname "*.mks" -or -iname "*.m4v" -or -iname "*.ogv" -or -iname "*.m2v"  -or -iname "*.mpv" -or -iname "*.ts" -or -iname "*.m2ts" -or -iname "*.avc" -or -iname "*.hevc" -or -iname "*.m1v" -or -iname "*.m2v" -or -iname "*.mpv" \) -print0 | xargs -0 -i{} sh -c " echo -n '{} ' && ffmpeg -i '{}' 2>&1 | sed -n -e 's/^.*bitrate: //p' " > result_bitrate.csv
      #ecrit le bitrate de toutes les videos d'un dossier dans le fichier result_mts.csv.
      # Ouvrir avec tableur et choisir séparateur ESPACE pour mieux visualiser les bitrate

      recuperer_toutes_infos_video_par_lot

      #!/bin/bash
      
      #recherche les informations des videos
      find . \( -iname "*.mkv" -or -iname "*.mov" -or -iname "*.mts" -or -iname "*.mp4" -or -iname "*.mpg" -or -iname "*.mpeg" -or -iname "*.flv" -or -iname "*.avi" -or -iname "*.webm" -or -iname "*.wmv" -or -iname "*.3gp" -or -iname "*.rm" -or -iname "*.asx" -or -iname "*.vob" -or -iname "*.f4v" -or -iname "*.mks" -or -iname "*.m4v" -or -iname "*.ogv" -or -iname "*.m2v"  -or -iname "*.mpv" -or -iname "*.ts" -or -iname "*.m2ts" -or -iname "*.avc" -or -iname "*.hevc" -or -iname "*.m1v" -or -iname "*.m2v" -or -iname "*.mpv" \) -print0 | xargs -0 -i{} sh -c " echo -n '{} ' && ffmpeg -i '{}' 2>&1 | sed -n -e 's/^.*Video: //p' " > result_toutes_les_infos.csv
      
      
      #ecrit les informations toutes les videos d'un dossier dans le fichier result_toutes_les_infos.csv.
      #Ouvrir avec tableur et choisir séparateur ESPACE pour mieux visualiser les bitrate

      stabiliser_video_par_lot_version

      #!/bin/bash
      # stabiliser des videos par lot
      
      echo -n "Sélectionnez la stabilité de la vidéo que vous souhaitez : 1 (trÚs stable) jusqu'à 10 (trÚs instable)  "
      read stabilite
      
      mkdir originaux
      # crĂ©e un rĂ©pertoire oĂč seront dĂ©placĂ©s les fichiers originaux aprĂšs conversion
      mkdir stabilisee
      #crĂ©e un rĂ©pertoire oĂč seront dĂ©placĂ©s les fichiers convertis
      
      for i in *.mkv *.MKV *.mp4 *.MP4 *.mts *.MTS *.avi *.AVI *.mov *.MOV *.webm *.WEBM *.flv *.FLV *.mpg *.MPG *.mpeg *.MPEG *.wmv *.WMV *.3gp *.3GP *.rm *.RM *.asx *.ASX *.vob *.VOB *.f4v *.F4V *.mks *.MKS *.m4v *.M4V *.ogv *.OGV *.m2v *.M2V *.mpv *.MPV *.ts *.TS *.m2ts *.M2TS *.avc *.AVC *.hevc *.HEVC *.m1v *.M1V *.m2v *.M2V *.mpv *.MPV ; do
      
          nice -19 ffmpeg -i "$i" -vf vidstabdetect=shakiness=$stabilite:accuracy=15 -f null - && \
      
      #shakiness=10 peut etre modifié en mettant shakiness = nombre_entre_1_et_10 : 1 video stable, 10 video trÚs instable
      
          nice -19 ffmpeg -i "$i" -vf vidstabdetect=shakiness=$stabilite:accuracy=15 -f null -&& nice -19 ffmpeg -i "$i" -vf vidstabtransform=smoothing=30:input="transforms.trf" "stabilisee_$i"
      
      rm transforms.trf
      
      mv "stabilisee_$i" ./stabilisee
          #déplace les fichiers convertis
          mv "$i" ./originaux
          #déplace les fichiers originaux
      done

      creer_video_cote_a_cote_par_lot

      #!/bin/bash
      #ce script va créer une vidéo à partir de deux vidéos, l'une que l'on peut nommer ma_video.mkv et l'autre qui doit alors se nommer stabilisee_ma_video.mkv
      #les deux vidéos seront cÎte à cÎte, ce qui permet de les comparer
      for i in *.mkv *.MKV *.mp4 *.MP4 *.mts *.MTS *.avi *.AVI *.mov *.MOV *.webm *.WEBM *.flv *.FLV *.mpg *.MPG *.mpeg *.MPEG *.wmv *.WMV *.3gp *.3GP *.rm *.RM *.asx *.ASX *.vob *.VOB ; do
      
      
      # la video d'origine correspond Ă  $i et l'autre video doit commencer par "stabilisee" mais il suffit de changer le prefixe si necessaire
      
          ffmpeg -i "$i" -i "stabilisee_$i" -filter_complex "[0:v]setpts=PTS-STARTPTS, pad=iw*2:ih[bg]; [1:v]setpts=PTS-STARTPTS[fg]; [bg][fg]overlay=w" "cote_a_cote_$i"
      
      
      done

      supprimer_bande_son_video

      #!/bin/bash
      #supprimer la bande son de toutes les videos (au format voir ci-dessous) d'un mĂȘme rĂ©pertoire et crĂ©e un fichier MKV sans bande son. Ne rĂ©encode pas la vidĂ©o.
      
      mkdir originaux
      # crĂ©e un rĂ©pertoire oĂč seront dĂ©placĂ©s les fichiers originaux aprĂšs conversion
      mkdir sans_son
      #crĂ©e un rĂ©pertoire oĂč seront dĂ©placĂ©s les fichiers convertis
      
      
          for i in *.mkv *.MKV *.mp4 *.MP4 *.mts *.MTS *.avi *.AVI *.mov *.MOV *.webm *.WEBM *.flv *.FLV *.mpg *.MPG *.mpeg *.MPEG *.wmv *.WMV *.3gp *.3GP *.rm *.RM *.asx *.ASX *.vob *.VOB *.f4v *.F4V *.mks *.MKS *.m4v *.M4V *.ogv *.OGV *.m2v *.M2V *.mpv *.MPV *.ts *.TS *.m2ts *.M2TS *.avc *.AVC *.hevc *.HEVC *.m1v *.M1V *.m2v *.M2V *.mpv *.MPV ; do
          nice -19 ffmpeg -i "$i" -c copy -an "$i.mkv"
      
          mv "$i.mkv" ./sans_son
          #déplace les fichiers convertis
          mv "$i" ./originaux
          #déplace les fichiers originaux
      
      
          done

      stabiliser_video_par_lot_en_testant_les_10_qualites

      #!/bin/bash
      # test toutes les qualitĂ©s de stabilisation pour un mĂȘme fichier
      
      # test les 10 qualités de stabilité
      
              for qualite in 1 2 3 4 5 6 7 8 9 10 ; do
                  for i in *.mkv ; do
      
                  # nice -19 ffmpeg -i "$i" -vf vidstabdetect=shakiness=$qualite:accuracy=15 -f null - && \
      
                  #shakiness=10 peut etre modifié en mettant shakiness = nombre_entre_1_et_10 : 1 video stable, 10 video trÚs instable
      
                  nice -19 ffmpeg -i "$i" -vf vidstabdetect=shakiness=$qualite:accuracy=15 -f null -&& nice -19 ffmpeg -i "$i" -vf vidstabtransform=smoothing=30:input="transforms.trf" "stabilisee_$i_$qualite.mp4"
      
                  rm transforms.trf
      
                  done
      
      
              done

      En conclusion

      Il faut du temps et de l’envie pour se lancer dans cette aventure, mĂȘme si le CPU fait 80 % du travail. Mais les 20 % restant ne sont pas Ă  nĂ©gliger. Entre les copier-coller qu’il ne faut pas rater, le classement des vidĂ©os par bitrate ou dimension, les vidĂ©os rĂ©encondĂ©es qu’il faut visionner (en accĂ©lĂ©rĂ©) pour s’assurer qu’elles sont correctes, etc. il faut vraiment rester concentrĂ© pour Ă©viter d’oublier une vidĂ©o ou, pire, de l’effacer alors qu’elle n’a pas Ă©tĂ© rĂ©encondĂ©e.

      Les avantages

      Mais je ne regrette pas tout ce temps, surtout pour avoir revisionné quasiment toutes mes vidéos, celle de mes enfants bébé (le coup de vieux en pleine figure), les moments en famille, les grands-parents disparus
 Cela a été des moments vraiment agréables.

      Cela m’a Ă©galement permis de ranger des vidĂ©os qui n’étaient pas dans le bon rĂ©pertoire ou de renommer celles qui comportaient une erreur dans leur nom.

      J’ai maintenant toutes mes vidĂ©os avec le mĂȘme format de conteneur (MKV), et les mĂȘmes codec vidĂ©o et audio, ce qui facilitera grandement un rĂ©encodage ultĂ©rieur.

      Et puis – c’était l’un des objectifs – le gain de place est trĂšs important puisque mon disque dur est passĂ© de 90 % Ă  48 % d’occupation (j’ai fait aussi un peu de mĂ©nage donc ce gain ne provient pas que du rĂ©encodage des vidĂ©os).

      Les inconvénients

      Est-ce une bonne idĂ©e de mettre tous ses Ɠufs dans le mĂȘme panier (un seul format de conteneur, un seul codec video, un seul codec audio) , mĂȘme si ces formats sont libres et, pour H265, lisible avec des logiciels libres, ce qui est tout de mĂȘme une bonne assurance pour l’avenir ?

      Du temps, du temps, et encore du temps : il faut en avoir pour ce projet (mais j’espĂšre que les scripts vous permettront d’en gagner)

      Cela consomme de l’énergie et, si beaucoup de gens veulent rĂ©encoder leurs vidĂ©os, l’impact environnemental ne sera pas nĂ©gligeable.

      L’opĂ©ration monopolise un ordinateur (nice -19 ne m’a pas paru trĂšs efficace quand je lançais trois encodages simultanĂ©ment!). Mais cela peut ĂȘtre l’occasion d’en utiliser un qui dort dans un placard et qui pourrait ainsi resservir.

      Si c’était Ă  refaire


      • Je le referai, sans aucun doute !
      • J’essaierai de conserver les mĂ©tadonnĂ©es (date, heure, coordonnĂ©es GPS) de mes vidĂ©os (mĂȘme si les informations les plus importantes sont dans leur nom) ;
      • Je tenterai d’utiliser le GPU pour le rĂ©encodage, ce qui rĂ©duirait le temps de calcul.

      Note pour le prochain confinement :

      [1] : je n'ai pas réussi à trouver l'équivalent de la commande jhead -autorot -nf%Y_%m_%d_%H%M_%S_ *.jpg pour les videos

      Commentaires : voir le flux Atom ouvrir dans le navigateur

      Degate : espionner un CPU depuis les waters

      Degate est un logiciel libre pour faire de l'ingénierie inverse sur les processeurs.

      Pour le présenter, Dorian Bachelot, mainteneur du projet, a accepté de répondre à nos questions.

      Logo Degate

      Sommaire

      Présentation

      Entretien avec Dorian Bachelot

      Présentation

      Qui ĂȘtes-vous ? Quel est votre parcours ?

      C’est sĂ»rement trĂšs « bateau Â», mais comme beaucoup je suis avant tout un passionnĂ© d’informatique et d’électronique. J’ai commencĂ© Ă  programmer dans mes annĂ©es collĂšge (dĂ©but des annĂ©es 2010) et suis rapidement arrivĂ© Ă  dĂ©couvrir Linux ainsi que d’autres galaxies (C++, git, virtualisation, reverse engineering
). Par la suite j’ai eu la chance de rĂ©aliser un diplĂŽme d’ingĂ©nieur Ă  l’ESIEA (Ă©cole d’ingĂ©nieur gĂ©nĂ©raliste sur Laval) qui m’a permis de dĂ©couvrir de nombreux domaines comme l’électronique embarquĂ©e, la cybersĂ©curitĂ© et l’intelligence artificielle. Comme beaucoup, j’ai un faible pour les domaines complexes et devoir me limiter Ă  une seule spĂ©cialitĂ© pour mes Ă©tudes ne m’allait pas trop. C’est sur ce dernier point que dĂ©marre l’aventure Degate au cĂŽtĂ© du laboratoire de recherche en cybersĂ©curitĂ© de mon Ă©cole. Cette derniĂšre proposait en effet un format « espoir recherche Â» permettant de creuser un sujet de recherche en plus des cours. Mon sujet a justement portĂ© sur Degate, puisque comme nous allons le voir la rĂ©tro-ingĂ©nierie matĂ©rielle a l’avantage de toucher autant Ă  l’électronique, qu’à la physique, la cybersĂ©curitĂ© et l’intelligence artificielle !

      Quant Ă  aujourd’hui, aprĂšs avoir travaillĂ© sur le sujet de la rĂ©tro-ingĂ©nierie matĂ©rielle pendant presque 3 ans (en publiant 5 articles dans Hackable et en travaillant sur Degate) et avoir obtenu mon diplĂŽme, je suis Tech Lead R&D Cyber/IA chez Neverhack (on vient de lever 100 millions d’euros). J’ai pu en effet garder une dualitĂ© de spĂ©cialitĂ©, Ă  travers la cybersĂ©curitĂ© et l’intelligence artificielle, principalement grĂące Ă  cette aventure d’espoir recherche (et donc en partie de Degate) 1.

      Est-ce que vous ĂȘtes parent de Roselyne ?

      Et non, du tout, mais bien vu ;)

      Qu’est-ce que Degate ?

      En une phrase : Degate est un logiciel open source (GPL-3.0) et multiplateforme aidant ses utilisateurs à effectuer de la rétro-ingénierie sur des puces de silicium 2.

      Maintenant, pour donner un peu de contexte, le dĂ©veloppement de Degate a commencĂ© dĂšs 2008 avec la thĂšse de master de Martin Schobert 3. Jusqu’à la fin de cette derniĂšre en 2011, Martin a pu faire Ă©voluer la solution et collaborer avec d’autres chercheurs pour l’utiliser sur des sujets de cybersĂ©curitĂ©. Par exemple, Degate a pu ĂȘtre utilisĂ© 4 pour aider Ă  la rĂ©tro-ingĂ©nierie de la puce RFID MIFARE Classic de NXP (le dĂ©veloppement de Degate a d’ailleurs pour source ce cas prĂ©cis). Par la suite, les chercheurs Karsten Nohl et Starbug ont pu trouver une faille cryptographique dans la puce permettant d’outrepasser toutes les sĂ©curitĂ©s (on parle ici d’un impact Ă©conomique Ă©norme pour NXP) 5.

      Degate est donc un logiciel avec une histoire riche de plus de 10 ans, qui a dĂ©jĂ  permis d’avoir un impact dans l’industrie (et, suite au cas MIFARE Classic, dans la sociĂ©tĂ©). Il est aujourd’hui le seul bastion permettant Ă  n’importe qui (ou presque) d’effectuer de la rĂ©tro-ingĂ©nierie matĂ©rielle sur des puces.

      Pourquoi dis-tu que c’est le seul bastion ?

      On peut voir ça sous diffĂ©rents angles, mais je parle d’unique bastion car Degate est le seul logiciel disponible Ă  la fois gratuit, accessible (traduction de l’interface, documentation, etc.) et extensible (car open source). Or, les alternatives payantes sont gĂ©nĂ©ralement vendues sous conditions et donc difficilement accessibles. Seulement, comme je l’ai expliquĂ© (modulo une dĂ©formation par mon parcours), la sĂ©curitĂ© d’aujourd’hui passe, pour moi, forcĂ©ment par une utilisation de la rĂ©tro-ingĂ©nierie matĂ©rielle beaucoup plus massive pour valider tout matĂ©riel critique. Et Degate n’est pas qu’un logiciel (surtout Ă  sa crĂ©ation en 2008, c’était plus un outil ou un dĂ©monstrateur), c’est aussi une preuve d’importance (MIFARE Classic) et des ressources en ligne (wiki, articles, thĂšse, etc.). Il ne faut pas seulement voir le logiciel (avec ses dĂ©fauts), mais plutĂŽt l’approche : essayer de rendre plus accessible la rĂ©tro-ingĂ©nierie matĂ©rielle. Je ne clame pas que Degate rĂ©ussit Ă  remplir cette vision, mais je crois que nous sommes quasiment les seuls Ă  essayer depuis maintenant plus de 10 ans (outre les projets visant Ă  « rĂ©tro-ingĂ©nierier Â» certaines puces en particulier, sans prendre le prisme de la sĂ©curitĂ© et de l’accessibilitĂ©).

      Comment ça fonctionne ?

      Avant tout il faut comprendre les contraintes et mĂ©thodes permettant d’effectuer de la rĂ©tro-ingĂ©nierie sur un objet aussi petit et complexe qu’une puce de silicium. Quand on parle d’une puce, on parle d’un agencement de milliards de transistors sur quelques millimĂštres et de leurs liens rĂ©partis sur plusieurs couches. La premiĂšre Ă©tape est alors de dĂ©finir un objectif, pouvant ĂȘtre la reconstruction d’un algorithme implĂ©mentĂ© matĂ©riellement (et donc dans une zone rĂ©duite de la puce) ou encore la reconstitution complĂšte du fonctionnement de la puce, par exemple pour construire un simulateur. Ensuite, il faut rĂ©ussir Ă  rĂ©cupĂ©rer des images de la puce et de toutes ses couches (images en 2D ou 3D, un de mes articles dans Hackable aborde le sujet 6). Toutes les mĂ©thodes permettant d’obtenir ces images impliquent un processus destructeur pour la puce. Cela passe par exemple par un processus de polissage itĂ©ratif et la prise de photographies (attention, on parle d’un exercice trĂšs complexe puisqu’une couche de silicium c’est extrĂȘmement fin, et trop polir implique de devoir recommencer sur une nouvelle puce). On peut aussi prendre une approche chimique (utilisation d’acide pour attaquer couche par couche) ou laser. Sans dĂ©velopper beaucoup plus, ce processus est le plus important, car c’est avec ces photos trĂšs hautes rĂ©solutions que l’on va pouvoir dĂ©buter l’analyse de la puce.

      C’est lĂ  que Degate rentre en jeu, son objectif est de permettre d’utiliser les images obtenues, de les importer dans le logiciel (on parle gĂ©nĂ©ralement d’images de plusieurs Giga, voire Tera, tellement la rĂ©solution et leur taille sont grandes) puis de commencer l’analyse. Ensuite, l’utilisateur peut analyser les parties de la puce en partant de la couche la plus basse, celle avec les transistors, et ainsi reconstruire les portes logiques (c’est ici que des connaissances en physique et en Ă©lectronique sont importantes, il faut savoir lire Ă  travers les transistors !). Comme vous vous en doutez, effectuer l’analyse de chaque transistor quand il peut y en avoir des milliards serait trop fastidieux, et Degate facilite le processus. Ce dernier propose en effet de construire une bibliothĂšque de portes logiques reconstituĂ©e depuis une zone de l’image de la puce, et puisque l’agencement des transistors ne change pas pour chaque porte logique, on peut alors automatiser la recherche et reconstitution de ces portes via des algorithmes de reconnaissance d’images. Il ne reste alors Ă  l’utilisateur qu’à analyser les connexions entre les portes logiques toujours grĂące aux images de la puce (couches supĂ©rieures, les liaisons entre couches sont appelĂ©es des « Via Â») et ainsi reconstituer les algorithmes utilisĂ©s par la puce. Degate permet lĂ  encore d’automatiser une partie du processus en aidant Ă  la reconnaissance des connexions et en proposant d’exporter toute l’analyse dans un langage type VHDL (permettant de simuler le fonctionnement de la puce, si l’analyse a Ă©tĂ© rĂ©ussie).

      Degate ne permet donc pas d’automatiser tout le processus de rĂ©tro-ingĂ©nierie, et une expertise humaine reste nĂ©cessaire (dĂ©capage de la puce, prise des photos, analyses des portes logiques puis des connexions), mais il permet de gagner un temps non nĂ©gligeable sur l’analyse en automatisant plusieurs Ă©tapes. Pour cela, Degate implĂ©mente des algorithmes de reconnaissances d’images, supporte l’importation d’images extrĂȘmement grandes (plusieurs millions de pixels de large), vous aide dans la navigation des images et couches, vous permet d’identifier les portes logiques formĂ©es par des transistors et bien plus.

      Si le sujet vous intĂ©resse, je peux vous donner les rĂ©fĂ©rences suivantes : on peut citer Ken Shirriff qui est LA personne Ă  suivre sur le sujet (auteur de beaucoup d’analyses sur des puces historiques 7, comme la Intel 8086 ou la fameuse Z80), ou encore la communautĂ© Visual 6502 8 qui ont rĂ©tro-ingĂ©nieriĂ© plusieurs puces (en partant de simples images pour finir par la crĂ©ation de simulateurs complets) ! Vous pourrez Ă©galement explorer le super site Silicon Pr0n 9. Enfin, pour trouver une liste plus complĂšte n’hĂ©sitez pas Ă  vous rendre directement sur le dĂ©pĂŽt de Degate 10.

      Il existe des protections contre ceci ? J’imagine que certaines entreprises n’aimeraient pas qu’on fasse de la retro-ingĂ©nierie sur leur puce, il me semble que certaines puces possĂšdent un genre de grillage.

      En effet, il existe beaucoup de mĂ©thodes pour essayer de s’en protĂ©ger. On parle de deux grandes catĂ©gories : les protections passives et actives. Les protections passives peuvent par exemple prendre la forme de rĂ©sine que l’on “coule” sur les puces pour complexifier leurs rĂ©cupĂ©rations (et aussi empĂȘcher la rĂ©cupĂ©ration des rĂ©fĂ©rences), ou d’une couche directement dans le silicium pour bloquer l’analyse visuelle de surface. D’autres mĂ©thodes existent, mais gĂ©nĂ©ralement de l’huile de coude et du bon matĂ©riel permettent de passer outre. Les mĂ©thodes actives sont plus recherchĂ©es et protĂšgent contre d’autres approches de la rĂ©tro-ingĂ©nierie matĂ©rielle. Comme citĂ© dans la question, l’ajout d’un grillage actif est une solution assez rĂ©pandue dans les puces de cartes bleues par exemple. L’idĂ©e est Ă  la fois de bloquer une analyse visuelle de surface de la puce, mais aussi d’empĂȘcher le “probing” (essayer d’utiliser une sonde directement sur un “circuit” de la puce) ou la modification de la puce (par exemple en connectant deux “circuits” de la puce). Cela passe par un maillage avec des formes complexes (on peut voir ça comme un labyrinthe) alimentĂ© par un courant qui, en cas de modification du circuit, peut rendre la puce non fonctionnelle. Il est alors compliquĂ© d’aller voir et manipuler les couches infĂ©rieures en laissant la puce fonctionnelle. 11

      Est-ce que les diffĂ©rentes façons de gravure qui utilise diffĂ©rent MOSFET (CMOS, FinFET, MBCFET, FD-SOI etc) ne demandent pas des analyses diffĂ©rentes ? Est-ce que ça sera fiable avec les derniers types de gravure avec des transistors imbriquĂ©s 3D ?

      À tout problĂšme sa solution : les mĂ©thodes d’analyses 3D de puces de silicium se dĂ©veloppent Ă©galement 6. Si le matĂ©riel nĂ©cessaire pour crĂ©er les donnĂ©es 3D venait Ă  ĂȘtre plus accessible, je prĂ©vois dĂ©jĂ  l’ajout d’un mode d’analyse Ă  Degate permettant de les exploiter. Je ne doute cependant pas que les mĂ©thodes d’analyses actuelles fonctionnent pour la majoritĂ© des cas, mĂȘme si le problĂšme est dĂ©jĂ  suffisamment complexe pour ne pas rajouter ces spĂ©cificitĂ©s. Je n’ai personnellement pas pu couvrir toutes les mĂ©thodes de gravures dans mes analyses ni les nouvelles approches en 3D. Seulement, ces mĂ©thodes s’appliquent pour l’instant majoritairement Ă  la mĂ©moire, ce qui n’est pas forcĂ©ment la cible des analyses.

      Qui se sert de Degate ? Est-ce une communautĂ© de fans de consoles ou des professionnels confrontĂ©s Ă  des puces qui ne sont plus documentĂ©es ou des gens du logiciel libre, etc. ?

      DĂšs ses premiers jours, Degate a Ă©tĂ© pensĂ© pour la cybersĂ©curitĂ©. L’idĂ©e Ă©tait de pouvoir faciliter l’analyse d’algorithmes implĂ©mentĂ©s directement dans les puces de silicium, Ă  la fois pour essayer d’identifier des failles, mais aussi pour vĂ©rifier la prĂ©sence de portes dĂ©robĂ©es. En effet, d’un point de vue sĂ©curitĂ© trop peu de personnes vont voir ces puces alors que tout dĂ©pend d’elles. Comment faire confiance Ă  un systĂšme si l’on ne peut pas vĂ©rifier la sĂ©curitĂ© de son composant le plus important et bas niveau ? Permettre Ă  des chercheurs et passionnĂ©s d’attaquer le sujet est ma principale motivation quand je travaille sur Degate, le sujet est pour moi majeur. On a trop tendance Ă  s’arrĂȘter Ă  la rĂ©tro-ingĂ©nierie logicielle, et c’est malheureusement un risque que l’on oublie trop.
      Je sais aujourd’hui que Degate est utilisĂ© (ou a Ă©tĂ© Ă©tudiĂ©) par des entreprises amĂ©ricaines dans le cadre de l’analyse de puces (je ne sais pas pour quel objectif), par la police allemande et par une universitĂ©.

      Malheureusement le domaine n’encourage pas beaucoup la communication et Degate pourrait ĂȘtre utilisĂ© ailleurs. J’ai d’ailleurs de gros doutes sur son utilisation par une entreprise amĂ©ricaine sous forme de fork non-partagĂ© (ne respectant alors pas la licence GPL qui est copyleft
). Mais ça, c’est un combat classique du monde libre (pour dire, on m’avait mĂȘme proposĂ© de me payer pour travailler dessus
).

      Mais autrement, le logiciel peut ĂȘtre utilisĂ© par d’autres communautĂ©s, comme pour les fans de vieux systĂšmes. Je sais que la communautĂ© qui s’occupe de rĂ©tro-ingĂ©nierer la PlayStation s’est dĂ©jĂ  intĂ©ressĂ©e Ă  Degate 12.

      Concernant la sĂ©curitĂ©, quels types de puces sont concernĂ©es ? J’imagine qu’il ne s’agit pas d’analyser les processeurs gĂ©nĂ©ralistes de nos ordinateurs
 Ce sont des puces qu’on trouve dans quels matĂ©riels ?

      C’est trĂšs large, gĂ©nĂ©ralement on parle de puces avec des missions/parties critiques. Par exemple (comme pour le cas MIFARE Classic), des puces implĂ©mentant des algorithmes cryptographiques sont importantes Ă  regarder : au niveau logiciel on recommande (et c’est un euphĂ©misme) de ne jamais rĂ©implĂ©menter ses propres primitives cryptographiques, pourtant beaucoup de puces le font (mĂ©thode simple pour booster les performances, aujourd’hui tout utilise de la cryptographie). Maintenant, on parle gĂ©nĂ©ralement de certaines parties/fonctions d’une puce plus que des puces entiĂšres. On peut par exemple citer en plus de la cryptographie tout ce qui concerne le stockage de donnĂ©es critiques (comme les clĂ©s de chiffrement). Aujourd’hui, je pense que l’on retrouve ces fonctionnalitĂ©s dans tout type de matĂ©riel.

      Comment en ĂȘtes-vous devenu le mainteneur ?

      Comme je l’ai expliquĂ© prĂ©cĂ©demment, c’est via un programme proposĂ© par mon Ă©cole d’ingĂ©nieur que j’ai Ă©tĂ© amenĂ© Ă  travailler sur le sujet de la rĂ©tro-ingĂ©nierie matĂ©rielle Ă  partir de fin 2018. Et comme Degate Ă©tait le seul programme gratuit et open source permettant d’automatiser une partie du processus (indispensable pour arriver Ă  des rĂ©sultats sans y passer 10 ans), j’ai rapidement eu l’occasion de pouvoir l’utiliser. Malheureusement l’auteur originel du logiciel ne contribuait plus au projet depuis quasiment 8 ans Ă  l’époque, et j’ai rapidement rencontrĂ© des difficultĂ©s pour l’utiliser plus largement dans mes recherches.

      AprĂšs quelques mois de travail et un refactor Ă  70 % du projet (j’ai par exemple refait toute la GUI en Qt5 + OpenGL moderne) pour repartir sur de bonnes bases, j’ai publiĂ© mon fork sur Github. Par la suite Martin (l’auteur originel de Degate) a prĂ©fĂ©rĂ© mettre le projet initial en archive sur Github, et faire une redirection vers cette nouvelle version (aujourd’hui refaite Ă  quasiment 80 % par moi-mĂȘme). L’idĂ©e Ă©tait de garder le nom et la communautĂ© mĂȘme si la grande majoritĂ© du logiciel a Ă©tĂ© refait.

      Maintenant, suite Ă  la fin de mes Ă©tudes, je dispose de moins de temps qu’avant et je suis forcĂ©ment moins actif. Mais j’essaie de traiter toutes les issues et pull request, tout en continuant Ă  travailler sur de nouvelles fonctionnalitĂ©s. Je cherche Ă©galement Ă  faire pĂ©renniser le projet en proposant Ă  des Ă©tudiants comme moi (Ă  l’époque) un financement pour travailler sur le sujet (et surtout Degate). Reste maintenant Ă  trouver des personnes motivĂ©es, car le sujet est vraiment complexe.

      Tu n’utiliseras donc pas Degate dans le cadre de ton travail ?

      Aujourd’hui non, mais je sais que la question se pose pour des collĂšgues. Le test d’intrusion matĂ©riel se dĂ©veloppe, et le sujet se pose de plus en plus. Maintenant les compĂ©tences nĂ©cessaires pour s’attaquer Ă  la rĂ©tro-ingĂ©nierie de puces de silicium sont un frein pour descendre aussi bas, sans compter le problĂšme du matĂ©riel (faut-il encore pouvoir dĂ©caper/dĂ©stratifier les puces avant de pouvoir commencer l’analyse). La solution actuelle est de pouvoir accĂ©der au design des puces (test en white box), mais les limites sont dĂ©jĂ  visibles (un matĂ©riel est gĂ©nĂ©ralement composĂ© de nombreuses puces de constructeurs diffĂ©rents).

      Quelle est ta motivation ? Qu’est ce qui t’anime avec Degate ? Puisque tu as commencĂ© l’informatique assez jeune, tu jouais peut-ĂȘtre avec des consoles ; est-ce que Degate te permet aussi d’imaginer recrĂ©er les puces de ton enfance ?

      Étant aujourd’hui un ingĂ©nieur chercheur portĂ© sur la cybersĂ©curitĂ©, cela me force Ă  voir Degate et la rĂ©tro-ingĂ©nierie matĂ©rielle Ă  travers ce prisme. Pouvoir permettre Ă  des chercheurs d’analyser des puces utilisĂ©es dans des millions de matĂ©riels Ă  travers la planĂšte est ce qui m’anime, mĂȘme si je ne doute pas que bien d’autres cas d’utilisations peuvent ĂȘtre tout aussi intĂ©ressants. Je suis par exemple aussi trĂšs portĂ© sur l’histoire, et la rĂ©tro-ingĂ©nierie matĂ©rielle est aussi un moyen de ne pas perdre certaines piĂšces de notre histoire.

      Est-ce que vous tirez un revenu de ce travail ? Est-ce une bonne wafer ?

      Je suis actuellement financĂ© 100$/mois par le mainteneur principal de Rizin/Cutter (logiciel de rĂ©tro-ingĂ©nierie software) et j’ai dĂ©jĂ  eu plusieurs autres propositions de financement. Ayant Ă©galement publiĂ© des articles sur le sujet, j’ai quand mĂȘme pu ĂȘtre rĂ©munĂ©rĂ© pour ce travail, mais on est trĂšs loin de quelque chose me permettant de vivre (et ce n’est pas l’objectif).

      Pour finir

      Que dire sur vos autres projets ?

      Au niveau personnel je travaille (quand j’ai le temps) sur une nouvelle approche IA au service de la cybersĂ©curitĂ© dĂ©fensive. Malheureusement mon temps est trĂšs limitĂ©, et j’évite de trop m’éparpiller. Au niveau professionnel je suis aujourd’hui Tech Lead et Team Leader sur un projet d’automatisation de cybersĂ©curitĂ© offensive. L’idĂ©e Ă©tant de crĂ©er un outil entiĂšrement automatisĂ© par IA permettant de jouer des attaques avec le mĂȘme niveau de sophistication que les vrais acteurs (gĂ©nĂ©ralement quand je parle du projet on me parle de Skynet, pour ceux ayant la rĂ©fĂ©rence). Un produit devrait sortir dans les deux ans, nous avons dĂ©jĂ  fait de nombreuses avancĂ©es scientifiques mais la route est encore longue. C’est aujourd’hui ce qui occupe le plus clair de mon temps !

      Que pensez-vous de la directive NIS 2 sur la cybersĂ©curitĂ© ?

      La France a Ă©tĂ© pionniĂšre en matiĂšre de rĂ©glementation dans le domaine de la cybersĂ©curitĂ©, et je pense que la directive NIS 2 se place dans le mĂȘme esprit que ce que l’on fait dĂ©jĂ  depuis plusieurs annĂ©es (avec la LPM de 2013 par exemple). Je sais que ces rĂ©glementations peuvent aussi faire peur, et l’accompagnement sera une condition nĂ©cessaire pour rĂ©ussir son application. Malheureusement je pense qu’il est nĂ©cessaire d’agir au plus vite, les rĂ©cents Ă©vĂšnements gĂ©opolitiques ainsi que les (trĂšs) nombreuses attaques observĂ©es chaque semaine imposent d’investir dans la sĂ©curitĂ© de nos entreprises. Je pense Ă©galement que comme la NIS 1, la NIS 2 n’est qu’une Ă©tape, et que des Ă©volutions seront nĂ©cessaires dans la prochaine dĂ©cennie pour Ă©tendre les attentes concernant la sĂ©curitĂ© des entreprises europĂ©ennes.

      Au niveau personnel, quels logiciels libres utilisez-vous, sur quel OS ?

      J’utilise depuis maintenant quatre ans Manjaro, venant de Debian/Ubuntu, et je suis trùs satisfait (le modùle rolling release me plaüt beaucoup à l’usage).

      Au niveau professionnel, quels logiciels libres utilisez-vous, sur quel OS ?

      Au niveau professionnel je tourne sur du Ubuntu 22.04, et j’utilise principalement du VS Code.

      Quelle est votre distribution GNU/Linux prĂ©fĂ©rĂ©e et pourquoi, quels sont vos logiciels libres prĂ©fĂ©rĂ©s ?

      Manjaro et Ubuntu sont les distributions que j’utilise dans la vie de tous les jours. Concernant les logiciels, la question est difficile puisque j’en utilise tellement. En ce moment je ne pourrais plus me passer de Joplin ou Signal, mais je pourrais en citer beaucoup (Virtual box, Kali linux, VSCode, Zotero
).

      Références

      Commentaires : voir le flux Atom ouvrir dans le navigateur

      ❌