FreeCAD est sorti le 18 novembre 2024 en version 1.0 (voir l'annonce officielle et sa vidéo associée). Cette sortie est marquée par une amélioration majeure : l'atténuation du problème de dénomination topologique.

Sommaire

• Qu'est-ce que FreeCAD ?
• Historique
• Le problème de dénomination topologique
• Les autres améliorations
  • Un outil d'assemblage par défaut avec solveur dynamique
  • L'atelier sketcher amélioré
  • Les ateliers Arch et BIM sont morts, vive la prise en charge native du format ouvert IFC
  • L'atelier FEM
  • Le reste
• L'essai commercial d'Ondsel

La dernière dépêche sur FreeCAD remonte à avril 2021 pour la sortie de la version 0.19. Depuis, il y a eu les versions 0.20 (juin 2022) et 0.21 (août 2023). Cette version 1.0 a porté le nom de 0.22 pendant son développement.

Qu'est-ce que FreeCAD ?

Extrait de wiki.freecad.org :
FreeCAD est un modeleur paramétrique de CAO 3D open source sous licence LGPL. FreeCAD est destiné à l'ingénierie mécanique et à la conception de produits mais — étant très générique — il s'adapte également à une gamme plus large d'utilisations autour de l'ingénierie, telles que l'architecture, l'analyse par éléments finis, l'impression 3D et d'autres tâches.

FreeCAD propose des outils similaires à CATIA, SolidWorks, Solid Edge ou Revit et entre donc également dans la catégorie CAO, GCVP, CFAO, IAO et BIM. Il s'agit d'un modélisateur paramétrique basé sur les caractéristiques d'une architecture logicielle modulaire qui permet de fournir des fonctionnalités supplémentaires sans modifier le système de base.

FreeCAD est aussi multiplateforme. Il fonctionne sous Windows, Linux/Unix et macOS avec la même apparence et les mêmes fonctionnalités sous toutes les plateformes.

Historique

La toute première version de FreeCAD est sortie en 2002. FreeCAD est développé en C++, Qt et Python et son cœur repose sur les bibliothèques OpenCASCADE (ou OCCT) spécialisées dans la CAO.

Son développement est assuré par un large panel de contributeurs : certains sont historiques, d'autres sont spécialisés sur un aspect particulier et beaucoup sont plus ou moins occasionnels.

Les versions se sont enchaînées à un rythme quasi annuel, apportant moult améliorations et fonctionnalités nouvelles.

En 2021, quelques contributeurs historiques fondent la FreeCAD Project Association (FPA) qui est un organisme indépendant à but non lucratif pour collecter des dons et apporter un soutien au développement du projet.
Ce soutien passe notamment par leur programme "FreeCAD Grant Program", qui permet d'embaucher ou de récompenser des personnes pour des projets spécifiques. Ce programme a un budget de 50k$ pour l'année 2024. A titre d'exemple récent, 500$ ont été octroyés pour une étude sur les runners CI de Github, 1000$ pour un gros travail de correction de bugs, et enfin 500$ pour la création d'une vidéo sur les nouvelles fonctionnalités de cette version 1.0.

FreeCAD bénéficie d'une communauté impliquée permettant notamment d'avoir une documentation complète, à jour et traduite dans de nombreuses langues.

Le problème de dénomination topologique

C'était un des points noirs de FreeCAD jusqu'à cette version 1.0.
Il faut imaginer que dans ce logiciel, la modélisation d'une pièce (dans le sens objet physique) passe par une suite d'opérations mathématiques et géométriques en définissant à chaque fois des contraintes ou des paramètres. Une opération est par exemple la création d'un trou borgne de 5 mm sur telle face à 10 mm des bords haut et gauche. Un autre exemple est d'ajouter une « languette » sur telle face cylindrique. Ou bien d'ajouter un chanfrein de 2 mm sur telle arête, etc.

Ainsi, petit à petit, la pièce modélisée se construit, prend forme, se détaille et se complexifie.

Cet historique de ces opérations successives est toujours présent et modifiable. À tout moment, il est possible de modifier une des étapes intermédiaires.

D'un point de vue technique, vous aurez sans doute compris que chaque opération s'applique à un élément précis et existant de la pièce à ce moment-là (une face ou une arête par exemple). Dans FreeCAD ces éléments ont tous un identifiant unique (Face6, Edge9, etc.), continu et incrémental. Si l'objet a 13 faces à une des étapes, les faces seront numérotées de Face1 à Face13. Chaque opération est rattachée à l'identifiant de l'élément (Face5 par exemple).

Et le problème se situe à ce niveau : lors d'une modification d'une étape intermédiaire, il arrive souvent que cela change la géométrie globale de la pièce et donc que les nombres de faces ou d'arêtes augmentent ou diminuent. Et FreeCAD réattribue alors ces identifiants uniques aux différents éléments.
Ainsi, si l'objet passe de 13 à 11 faces, c'est l'ensemble des faces qui vont recevoir un nouvel identifiant dans la plage Face1 à Face11, avec un très fort risque qu'une face, pourtant non touchée par la modification, porte un identifiant différent.

Et vous voyez le problème arriver : si une des opérations suivantes dans l'historique était de faire un perçage sur la Face6 qui est maintenant devenue la Face3… Toute la modélisation part en vrille.

Ce problème de dénomination topologique est documenté sur le wiki de FreeCAD : problème de dénomination topologique.

Pour éviter cela, il était conseillé de suivre un ensemble de bonnes pratiques de modélisation sous FreeCAD : Édition de fonctions. Il faudra certainement suivre l'évolution de cette page avec cette sortie.

Cette version 1.0 marque donc l'intégration de codes correctifs de cette problématique. Les notes de version indiquent tout de même que tout n'est pas résolu, et qu'il y aura d'autres améliorations dans les prochaines versions. Cette petite vidéo en anglais vous montre la différence de comportement entre la version 0.21 et 0.22dev (qui a servi de base à la 1.0).

Les autres améliorations

Un outil d'assemblage par défaut avec solveur dynamique

Le terme assemblage désigne la fonctionnalité de regrouper plusieurs éléments afin d'obtenir un objet fonctionnel. Ce peut être, par exemple, une boîte constituée d'un couvercle sur charnières maintenues par des vis avec des rangements amovibles à l'intérieur. Ou bien un moteur thermique avec ses carters, vilebrequin, bielles, pistons, soupapes, etc. Il est parfois utile de pouvoir fournir des indications de positionnement et/ou de liberté des éléments entre eux, et de pouvoir animer le tout.
Ces opérations d'assemblage n'étaient pas intégrées dans FreeCAD avant la version 1.0. Elles étaient néanmoins possibles grâce aux ateliers. Plusieurs ont été créés pour cela avec chacun leurs spécificités et leurs approches mais aussi une incompatibilité entre eux : A2plus, Assembly3 ou Assembly4.
Cette version 1.0 propose un nouvel atelier mais intégré par défaut. Il a été mis au point par la société Ondsel (voir plus bas). Il est encore jeune, et il est encore trop tôt pour savoir s'il finira par s'imposer par rapport à l'existant déjà en place. Un tutoriel concernant l'atelier d'assemblage est d'ores et déjà disponible pour une introduction à cette nouvelle fonctionnalité de la v1.0.

L'atelier sketcher amélioré

Cet atelier permet de dessiner les esquisses techniques utilisées dans la conception mécanique. C'est dans celui-ci que sont dessinés les « plans 2D » avec les cotes et les contraintes dimensionnelles et spatiales. Cette version apporte un nombre conséquent d'améliorations et de nouvelles fonctionnalités rendant son utilisation plus facile, plus puissante et plus rapide. Le mieux est de regarder les notes de version animées.

Les ateliers Arch et BIM sont morts, vive la prise en charge native du format ouvert IFC

Si le titre est cryptique, c'est que l'on parle de BTP et d'outils destinés aux équipes de Maîtrise d'Œuvre impliquées dans la conception d'une opération construction (Architectes, Bureaux d'Études). Comme ce n'est pas forcément le lot commun des visiteurs de LinuxFr.org, résumons la situation:

• L'atelier Arch, pour Architecture, exploite depuis longtemps les capacités de création 3D de FreeCAD pour dessiner facilement, fondations, murs, planchers, fenêtres, portes etc. Cet atelier se basait sur le format natif des fichiers FreeCAD, *.FcStd.

• Dans l'atelier BIM (pour Building Information Model <= l'article Wikipedia_FR est bien écrit pour qui veut comprendre l'essentiel), on retrouve un certain nombre d'outils de dessin et de création d'objets qui s'avèrent redondants pour certains avec ceux de l'outil Arch tout en implémentant les paradigmes bien plus vastes qu'induit l'approche BIM d'un projet de construction <=> pas uniquement de la géométrie, mais aussi du prix, des données mécaniques, physiques, des fiches produit, du planning …

• L'approche BIM tend à se généraliser dès lors que la complexité et le coût du projet le justifient. Elle repose (en théorie) sur un format d'échange IFC (pour Industry Foundation Class).
  Il est ouvert et au format texte.
  Oui avec vim, c'est possible de bidouiller ;)
  mais un fichier IFC fait rapidement quelques centaines de Mo voire quelques Go …

L'Association "Building Smart" en définit les caractéristiques. Tous les logiciels sur le marché savent ouvrir et exporter dans ce format, à la norme IFC 2.3 ad minima et IFC 4.2 voire 4.3 pour les up to date.

L'atelier BIM de FreeCAD utilisait jusqu'à présent IfcOpenShell, une application tierce Open Source pour convertir un fichier du format *.ifc vers du *.FcStd en passant (sans doute) par du OpenScad dans le processus.

Une image qui devrait parler au LinuxFrien (!) pour la classe IFC Material-Constituent-Set,

Pour la version 1.0 de FreeCAD, Yorik Van Havre, développeur historique de FreeCAD, (par ailleurs, architecte et Président la FreeCAD Project Association) a entrepris de fusionner ces deux ateliers, d'en faire une fonctionnalité native de FreeCAD, c'est-à-dire qui se passe du vaillant IfcOpenShell (grâce notamment au travail fait sur Blender-Bim) pour que FreeCAD puisse ouvrir et enregistrer directement au format IFC sans conversion inutile.

L'atelier FEM

Cet atelier d'analyse par éléments finis comporte également des améliorations considérées comme majeures avec cette version 1.0, détaillées dans un article de blog sur l'atelier FEM de FreeCAD.

Les avancées majeures sont liées à la prise en charge de fonctionnalités de CalculiX, un des solveurs utilisés par cet atelier : symétrie cyclique, analyses 2D et contraintes de corps rigide.

Le reste

Comme à chaque nouvelle version, beaucoup de choses ont été apportées, que ce soit dans l'interface, ou dans la plupart des ateliers intégrés. Les notes de version de la v1.0, comme très souvent détaillées en images, permettent de voir l'évolution de ce logiciel.

FreeCAD a également annoncé son nouveau logo, choisi après un appel à concourir auprès de la communauté (lien). Le logo en SVG est disponible sur cette page.

L'essai commercial d'Ondsel

Outre la création en 2021 de l'association FPA (voir plus haut), d'autres développeurs, notamment Brad Collette, mainteneur de longue date de l'atelier Path et auteur de deux livres sur FreeCAD, ont créé début 2023 la société américaine ONDSEL sous la forme d'une Public Benefit Corporation (PBC) qui pourrait se traduire par « une entreprise d'intérêt pour la société ». Malheureusement, après environ 2 ans, Brad Collette informe de l'arrêt de la société ONDSEL, faute d'avoir trouvé un marché.

La société voulait s'appuyer sur FreeCAD pour « apporter des fonctionnalités commerciales qui rendent FreeCAD plus utile aux utilisateurs commerciaux ». (Source)

Pour cela, ONDSEL a produit sa propre version de FreeCAD avec ses propres choix esthétiques et ergonomiques, et a fourni un cloud pour simplifier le travail en équipe et le partage.
À noter qu'ONDSEL indiquait soumettre ses améliorations à FreeCAD pour intégration et que son cloud était disponible sous forme de module dans FreeCAD. Ces améliorations se retrouvent dans cette version 1.0 de FreeCAD, notamment le nouvel outil intégré d'assemblage ainsi que les très nombreuses nouvelles fonctionnalités de l'atelier Sketcher.

La société ONDSEL avait détaillé sa relation avec le projet FreeCAD indiquant notamment leur mode de collaboration. Ils avaient également un blog en anglais intéressant, où ils abordent plusieurs thématiques, notamment sur l'évolution de CATIA ou bien la liste des nouveautés agrémentée de nombreuses animations.

Dans l'annonce de cet arrêt, Brad Collette revient également sur ce qu'ils ont apporté au projet FreeCAD. Tout ce qu'ils ont développé était en open source et déjà intégré pour la plupart à FreeCAD. Les fondateurs d'ONDSEL continueront de contribuer au projet directement.

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.

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
  • Écran de démarrage (Splash Screen)
  • Améliorations du thème d’icônes Legacy
• Invasion de l’espace colorimétrique
• Finalisation de l’API publique
• Mises à jour de l’édition non destructive
• Interface utilisateur
• Greffons
  • BMP
  • TIFF
• GEGL et babl
• Statistiques de sortie
• Modifications futures du processus de publication
• Autour de GIMP
  • Miroirs de téléchargement
  • Modifications de l’infrastructure
  • Accord d’hébergement fiscal de la Fondation GNOME
  • Traductions
• Télécharger GIMP 3.0 RC1
• Et ensuite ?

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 !

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 !

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.

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)

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 !

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 ! 💪🥳

Ben oui, ce sujet m’intéresse car je suis motivé par la préservation de ce que je considère comme précieux dans les données que je crée ou récupère sur mon PC. En tant que bidouilleur j’ai moi aussi créé un outil pour cela. Il correspond à mon besoin et j'en suis satisfait. Voici mon cheminement.

J’ai fait une recherche sur LinuxFR.org avec le mot sauvegarde et j’ai trouvé des articles et des réactions toutes très intéressantes. Les besoins, les solutions, les mises en œuvre sont très variées. Chacun choisit ou crée selon son ressenti et finit par être satisfait de ce qu’il fait. Chacun partage son expérience, en espérant qu’elle profitera à d’autres. À mon tour.

Le meilleur outil de sauvegarde est celui qu’on utilise et en lequel on a confiance.

Je te propose un jeu : demande à un utilisateur de PC, smartphone… si la destruction inopinée de son appareil entraînerait des pertes de fichiers irrémédiables qui pourraient l’affecter (photos familiales, documents…). Demande ensuite s’il fait des copies et/ou des sauvegardes. Pour beaucoup, tu seras catalogué comme vilain geek alarmiste. Il y a du travail de prise de conscience !

Sommaire

• Notion de sauvegarde
• Que demande-t-on à un outil de sauvegarde ?
• Un script shell écrit sur un coin de table (au début)
• Scripts bash tzsauv
• Subtilités et pièges
• Conclusion

Notion de sauvegarde

Une analyse très courte de la fonction sauvegarde serait « ranger quelque part des données qui permettront de restituer ce que je considère comme précieux ».
Les mots clés sont « ranger » « quelque part » « données » « restituer » « précieux ».
On a deux verbes « ranger » « restituer », deux localisations de données « quelque part » « ce qui est précieux », et une notion de filtrage dans le mot « précieux ».

Un autre point de vue serait de dire qu’une information précieuse doit résider en deux endroits, pour que la défaillance de l’un puisse être compensée par l’autre. Une des conséquences consiste à doubler les archivages : la libération des espaces précieux par la suppression de données inactives doit être précédée de l’archivage des données à supprimer vers deux supports distincts. Une autre conséquence est d’utiliser un média spécifique pour recevoir les sauvegardes (autre que celui où sont les données à sauver).

La défaillance peut être de plusieurs origines : matérielle, corruption du média, utilisateur qui efface/écrase…

Que demande-t-on à un outil de sauvegarde ?

Si je rédigeais un cahier des charges pour un outil de sauvegarde, je ferais les listes suivantes. Je suis dans mon contexte de PC isolé, ayant accès éventuellement à un petit serveur sur le réseau local.

Fonctionnalités de base :

• sauver juste ce qui a été modifié depuis la sauvegarde précédente => opération rapide,
• compression des fichiers archives => prend peu de place sur l’espace de sauvegarde,
• facile à lancer et rapide en exécution => sera lancé souvent => sécurisation accrue,
• filtrage => possibilité de conserver dans les espaces sauvés des fichiers qui n’encombreront pas les sauvegardes,
• robuste => confiance.

Fonctionnalités nécessaires :

• vérification de l’intégrité des fichiers archives engendrés,
• restitution facile malgré le grand nombre de fichiers archives à exploiter,
• restitution qui permette de régénérer (ailleurs) l’espace sauvegardé dans le même état que ce qu’il était au moment d’une des opérations de sauvegarde (accès aux états antérieurs),
• recherche/extraction de fichiers dans le grand nombre de fichiers archives obtenus,
• traçage pour vérifier le bon déroulement des opérations.

On peut ajouter aussi :

• algorithme ouvert et source fourni,
• qui s’accommode de tous types de support de stockage,
• qui utilise des formats standard,
• qui a toutes ses fonctionnalités accessibles en ligne de commande.

Le dernier point permettra d’utiliser l’outil comme une commande classique. On pourra le lancer dans un script bash qui adaptera l’usage au besoin spécifique du moment (ajout de montage/démontage du média de sauvegarde, rsync réseau des fichiers générés…). C’est une commodité qui me manque quand je suis coincé dans l’usage d’un outil cliquodrome.

Un script shell écrit sur un coin de table (au début)

J’ai rencontré le shell lors de mon premier contact avec Unix, en 1987. Au début j’ai eu le sentiment de régresser par rapport à la syntaxe COM des Vax/VMS. Depuis, j’ai appris à apprécier le bash, bien plus commode que ses ancêtres sh csh. Une des philosophies du shell est de combiner des commandes simples et robustes pour en faire une réponse à un besoin. Par exemple ls | wc -l renvoie le nombre de fichiers/répertoires du répertoire courant. Toutefois, il y a des cas sournois où le résultat est faux, on verra plus loin ce que je qualifie de pièges.

Avec les pipelines, les redirections, les variables, les traitements de chaînes de caractères, et tout le reste, on peut construire à l’infini des séquences d’opérations qui s’appuient sur des commandes simples à lancer mais puissantes (genre outil de compression, outil de parcours d’une arborescence de fichiers…). Beaucoup des fonctionnalités du système GNU sont construites comme cela. Un bidouilleur système ne peut pas ignorer le bash. En plus, emacs permet un accès très commode aux man. Je n’ai jamais eu de projet ou de besoin qui me pousse à maîtriser Perl ou Python. Je pense qu’ils sont encore plus puissants que bash.

Comme j’aime bien bidouiller, à la fin du 20^e siècle j’avais dans l’idée de faire un outil de sauvegarde basique qui s’appuie sur un pipeline : une commande find qui sélectionne les fichiers modifiés, tar pour les copier et gzip pour compresser. J’ai fait divers essais. En 2021, je m’y suis mis sérieusement et j’ai découvert beaucoup de subtilités du bash.

Un des problèmes des sauvegardes incrémentales est de deviner si un fichier doit être sauvé, sans avoir à comparer son contenu avec la version sauvée dernièrement (ça coûte trop cher). Il faut se baser sur les paramètres du système de fichiers. Il faut bien choisir ces paramètres (on surveille leur changement), au risque de rater certains fichiers ou alors d’en sélectionner trop. Je me suis arrêté sur la date de modification du statut et le numéro d'inode.

Scripts bash tzsauv

Je pense être arrivé au bout des spécifications avec l’outil tzsauv que j’ai écrit en bash. Il est disponible sur mon site.
Je m’en sers quotidiennement. Selon les jours, j’envoie les fichiers archives sur le 2ᵉ disque ou sur clé USB. Je fais aussi un miroir du répertoire disque des fichiers archives vers GoogleDrive (ceinture et bretelles). Je fais aussi une sauvegarde à longue périodicité (six mois) sur une clé USB dédiée (double ceinture).

Les opérations principales utilisent les commandes standard find sed tar zstd md5sum, le bash sert à enchaîner tout ça et sert aux dialogues. Pour installer, il suffit de copier deux scripts sur le média de sauvegarde (SauverTZ_ProjXY_01.bash tzsauv.bash, total 96k, ajouter éventuellement l’aide Alire.txt), et modifier quelques paramètres dans l’un des scripts (le script lanceur SauverTZ_*.bash). Le lancement peut se faire en ligne de commande ou via l’explorateur de fichiers par Clic-Droit/Actions/LancerDansKonsole.

L’interprétation du bash prend des ressources, mais je pense qu’elles sont négligeables par rapport à celles prises par les E/S et les commandes standard citées ci-dessus. Le compresseur zstd semble être très performant, en temps et en taux de compression. De plus, il est multithread, ce qui lui permet de tirer avantage des processeurs actuels qui gagnent en puissance en augmentant le nombre de cœurs. Le paramétrage de tzsauv permet de choisir parmi plusieurs formats d’archives.

Pour la sauvegarde vers le 2^e disque, j’ai copié sur le Bureau le lanceur de Konsole, puis j’ai renommé la copie et dans ses Propriétés/Application j’ai modifié l’argument (-e ./SauverTZ_ProjXY_01.bash) et le dossier de travail. Du coup, avec juste un double-clic je lance la sauvegarde en mode interactif (-> question « … TOTALE o/n/q ? »). Elle est pas belle la vie ?

Subtilités et pièges

Je fais régulièrement des petits programmes bash pour explorer des détails de fonctionnement soit du bash, soit des commandes. Les man ont beau être détaillés, ils ne peuvent pas tout dire. Pour un bug de tar je suis allé jusqu’à consulter le source C, le corriger par plaisir et vérifier que c’était OK. La remontée du bug n’a pas abouti (personne n’utilise l’option -u de tar ! C’est de la tétrapilectomie, je suis xyloglotte mais pas encore alopécique).

Si tu lances sous bash ls | wc -l puis touch -- 'a'$'\n''b' puis de nouveau ls | wc -l, le nombre renvoyé aura augmenté de deux alors que tu n’as ajouté qu’un seul fichier. C’est normal car le nom du fichier ajouté tient sur deux lignes ! Solution : ls -q | wc -l ou ls --zero | tr '\n\0' '\0\n' | wc -l. Pour voir le résultat de ls -q envoyé à wc -l via le pipeline, entrer ls -q | cat.

Les deux seuls caractères interdits dans les noms de fichiers/répertoires *unix* sont « / » et « \0 » (à méditer).

Je t’invite à créer sous bash un fichier piège par echo "abcd" > $' xyza\x01b\x02c\x03d\x04e\x05f\x06g\x07h\x08i\x09j\x0ak\x0bl\x0cm\x0dn\x0eo\x0fESC\x1bDEL\x7f\x80\xff\x26\x22\x27\x60\x5c SPC ', à le sauver avec ton outil, puis à le restituer. Tu verras si ça passe et si le nombre de fichiers est correct. Pour le détruire rm -i *xyza* devrait convenir.
Essaye aussi avec un sous-répertoire mkdir $' xyzp\x01b\x02c\x03d\x04e\x05f\x06g\x07h\x08i\x09j\x0ak\x0bl\x0cm\x0dn\x0eo\x0fESC\x1bDEL\x7f\x80\xff\x26\x22\x27\x60\x5c SPC '. Mets-y un fichier, puis fais une sauvegarde totale, modifie le fichier et fais une incrémentale. Ensuite fais un essai de restitution. Joue aussi à modifier le nom du répertoire parent du sous-répertoire piège.
Pour jouer avec ces choses dangereuses, je te conseille de faire une zone à part, ne fais pas courir de risque à ta production. Sur ma Mageia9.2-official, le navigateur Dolphin n’arrive pas à détruire le répertoire piège. Je passe par la ligne de commande.

J’ai rencontré tout plein de pièges et j’en ai imaginé d’autres : un fichier de nom -f, un répertoire de nom -, comment détruire le fichier ? Comment faire un cd vers le répertoire ?
Solutions : rm -f -- -f et cd -- -/ et si le nom du répertoire est dans la variable var cd -- "${var%/}/" (prévoir le cas où var="/").
J’ai découvert que zstd en mode filtre lancé par tar, se met en erreur s’il existe un sous-répertoire de nom - dans le répertoire courant (c’est très particulier, en effet). L’examen des sources de tar et de zstd m’a confirmé le problème, la solution m’a parue simple (inverser l’ordre de deux tests dans le source de zstd) mais la remontée de bug n’a pas abouti. Ce n’est pas grave, je sais maintenant qu’il ne faut pas utiliser tar ... --zstd ..., et je mets plutôt zstd -c[d] dans un pipeline.

J’en raconte un maximum dans le fichier notes01.bash. Toute cette expérience me permet de créer des scripts bash robustes.

Conclusion

Ton outil de sauvegarde est le meilleur, car il te convient.
Fais-toi une idée claire

• de tous tes espaces contenant des fichiers précieux à tes yeux,
• de tous tes espaces de sauvegarde,
• des mécanismes de sauvegarde et de restitution.

Cela participe à la confiance.

N’oublie pas de faire de temps en temps un contrôle d’intégrité des archives et un exercice de restitution. C’est un peu de travail, juste pour vérifier qu’une mise à jour, ou une donnée inhabituelle, ou autre chose, n’a pas mis en défaut la capacité à restituer comme tu l’entends.

Si la restitution est rendue impossible, c’est comme si tu n’avais jamais sauvegardé !

La confiance, en informatique ça se surveille du coin de l’œil
L’informatique est une science exacte pour la machine, pas pour l’homme ; il compense par l’humilité et l’empirisme