Linux Just Standardized Something We All Use

SYNTHÈSE STRUCTURÉE

Contexte : le besoin d’un dossier standardisé pour les projets

L’intervenant part d’un constat simple : « Most of us have some sort of folder for things that we’re working on. » Que ce soit pour du code source, des modèles 3D, des fichiers CAO ou des projets scolaires, chacun a son propre système. Or, il existe déjà des dossiers standardisés comme Desktop, Documents, Downloads, Music, Pictures, Videos – définis par la spécification free desktop XDG user dirs. L’idée d’ajouter un dossier Projects s’inscrit dans cette logique de standardisation.

Origine : une proposition vieille de 19 ans

Le dossier Projects n’est pas une idée récente. L’intervenant révèle que « Projects directory created September 15th, 2014 by Bugzilla migration user », mais que le code existait déjà bien avant : « If we go to this commit here, this is from February 27th, 2007, initial revision. Projects is defined in the translate.c file. » En réalité, 99 % de l’implémentation était déjà présente dans le code source, mais la dernière étape – la définition comme dossier par défaut – n’avait jamais été finalisée. « Somebody thought it was a good idea to have a projects folder. They were working on a projects folder. And then they didn’t finish the entire chain of things they needed to do to fully implement the folder. »

Pourquoi un dossier dédié plutôt que le répertoire personnel ?

L’intervenant explique que les projets logiciels contiennent « source code, version control, compiled binaries, test artifacts, and downloaded dependencies ». Ces éléments ne rentrent pas dans Downloads (car conservés indéfiniment) ni dans Documents (trop générique). Un dossier standardisé permettrait aux scripts d’installation ou aux README de télécharger automatiquement le code source dans un emplacement connu : « when writing a readme or install script for a project, one could automatically download the source to the user-defined location, set up the build environment, and install from there. »

Cas d’usage : Flatpak et applications propriétaires

Un point technique important concerne les applications Flatpak. L’intervenant précise : « For a lot of the proprietary applications which support Linux but don’t support the flat-packed format, you need somewhere for them to go because they won’t just be able to access everything unless you just ignore the sandbox and give them access to the entire system. » Un dossier Projects dédié résout ce problème en offrant un point d’entrée unique pour les applications sandboxées, sans compromettre la sécurité.

L’implémentation : une modification d’une seule ligne

La fusion du dossier Projects dans le code source a été étonnamment simple : « This got merged with literally no hassle because it’s a single line change. All the code was already there. » L’intervenant souligne que le code existait depuis 19 ans, mais qu’il manquait juste l’activation par défaut. La modification se résume à définir projects comme dossier par défaut dans la configuration XDG.

Délais de déploiement et réactions de la communauté

L’intervenant met en garde contre l’impatience : « Flatback still has no idea what XDG projects is if you add it to the file systems override. It needs some time to get shipped by distros. Definitely more than being in Git for 10 minutes. » Il précise que les distributions rolling release (comme Arch Linux) l’ont déjà intégré, mais que les versions stables (Ubuntu, Debian) devront attendre le prochain cycle de mise à jour. Une modification complémentaire dans GLib est encore en cours, probablement pour la prochaine version majeure de GNOME.

Icône et design : un travail en cours

L’intervenant aborde la question de l’icône du dossier : « Doing icon design, doing any sort of design does take a bit of time. You have to go through design review and make sure it fits the styling guidelines. » Il estime que l’icône sera finalisée « in a couple of weeks, maybe a couple of months », mais que le dossier fonctionne déjà sans icône personnalisée.

Problème persistant : les applications qui ignorent les standards

L’intervenant reconnaît que même avec un standard, certaines applications continueront à polluer le répertoire personnel : « Even though config has been defined in XDG user DERS probably since the very start of the project and has existed and a lot of applications do make use of it, there are still apps which spam their configs in the home directory. » Il cite Android Studio comme exemple : « Here’s your Android Studio projects. Here are your other various projects. Here’s your other projects. Here’s your other ones. And that gets really, really messy. » Certaines applications recréent leur dossier à chaque ouverture s’il est supprimé.

Avantage clé : la configurabilité via XDG

Le vrai pouvoir de la spécification XDG User Dirs réside dans la possibilité de redéfinir l’emplacement des dossiers : « The power of XDG user DERS is you can go and redefine the directory into a new location. So if you don’t want these in your home directory, you can put them into their own subdirectory. » L’intervenant nuance toutefois : « Like config though, there are applications which use config but they don’t actually use the XDG setting. All they do is hard code the path. So you change it and all they do is just make their own config folder again. »

Conclusion : un pas vers l’amélioration

Malgré les imperfections, l’intervenant considère cette évolution comme positive : « Even though there are apps that are not going to use it, it’s still a good change because it sets the pathway for things to improve, for things to get better. If you don’t set that path, then nothing is going to change. » Le dossier Projects standardisé offre une base pour que les développeurs d’applications adoptent progressivement une meilleure organisation.

CONCEPTS CLÉS

XDG User Dirs : Spécification freedesktop.org définissant les dossiers utilisateur standardisés (Desktop, Documents, Downloads, etc.) et leur emplacement configurable via des variables d’environnement.
Flatpak : Système de conteneurisation d’applications Linux qui isole les applications du système hôte. Le dossier Projects permet de donner un accès limité et sécurisé aux fichiers de projet.
GLib : Bibliothèque de bas niveau utilisée par GNOME et d’autres environnements. La modification dans GLib est nécessaire pour que Nautilus (le gestionnaire de fichiers) reconnaisse et affiche correctement le dossier Projects.
Hard coding : Pratique consistant à écrire en dur un chemin dans le code source, ce qui empêche l’utilisateur de le modifier via les variables XDG.

CONCLUSION

L’ajout du dossier Projects dans la spécification XDG User Dirs est une évolution mineure en apparence (une seule ligne de code), mais majeure pour l’organisation des fichiers sur Linux. Elle répond à un besoin réel : éviter que les applications ne dispersent leurs données dans le répertoire personnel. Même si toutes les applications ne respecteront pas immédiatement ce standard, l’intervenant insiste sur le fait que « it sets the pathway for things to improve ». Pour l’administrateur système, c’est un pas vers une gestion plus propre et plus prévisible des projets, avec la flexibilité de redéfinir l’emplacement via les variables XDG. Si vous utilisez une distribution rolling release, vérifiez si le dossier ~/Projects existe déjà ; sinon, vous pouvez le créer manuellement et commencer à l’utiliser en attendant son adoption généralisée.