Amongst the advantages of following this specification, I list :
- a lot less cluttered $HOME (my mother will not cry anymore when the gtk file selector randomly choose to display hidden folders)
- Make backups a lot more safer and easier. (you know that backuping your $XDG_DATA_HOME along with your files is enough)
- A lot easier to reset a default configuration if you want/need it (and without any risk to loose informations). Even for the software itself could choose to reset $XDG_CONFIG_HOME if needed.
- Avoid some strange bugs that happens because you had a old version of some configuration file
- A lot more of flexibility and portability because no path are hardcoded. You use the XDG library that does the job for you. If you don’t want the dependency, implementing the XDG specification is only a few lines of code.
How does it work ?
Your application should not have its own folder anymore (and should not use another software hidden folder like .gnome2).
User data should go into $XDG_DATA_HOME (which default to .local/share), user preferences should go into $XDG_CONFIG_HOME (which default to .config) and cached data should go to $XDG_CACHE_HOME (which default to .cache).
But how do you know what goes in what folder ?
There’s a little trick : just imagine that it was deleted. What would you think as a user ?
If you would cry, running frenetically to your backup, it means that it belongs to XDG_DATA_HOME.
If you would think « Damn, I will have to reconfigure all », it belongs to $XDG_CONFIG_HOME. This includes user installed plugins even if those plugins might themselves have files in XDG_DATA_HOME. The exception I see is the usernames/passwords for external services. Those are clearly configuration stuffs but, imho, just fit better in XDG_DATA_HOME.
If you would just think « It’s bloody slow those days » then it is obviously part of XDG_CACHE_HOME.
Of course, I’m sure there is some corner cases. But take the time to choose carefully instead of just putting everything in XDG_DATA_HOME, defeating the purpose of this specification.
Think about your users !
A lot of applications are already following this specification (VLC, Wormux, Totem, Metacity, Cheese, Deskbar, Pyroom, Getting Things Gnome) or will soon (Rhythmbox has it in SVN, GStreamer will have it for 0.11,..)
And you ? Is your application already XDG compliant ?
PS : If you are not the maintener of any applications, sending a patch to your favourite project might be a great contribution. If you never contributed code to any project, take this opportunity : writing a XDG patch is really easy to do and it could be your first step to world domination.
Vous avez aimé votre lecture ? Soutenez l’auteur sur Tipeee, Patreon, Paypal ou Liberapay. Même un don symbolique fait toute la différence ! Retrouvons-nous ensuite sur Facebook, Medium, Twitter ou Mastodon.
Ce texte est publié sous la licence CC-By BE.