Modify your application to use XDG folders
by Ploum on 2009-03-11
As I previously pointed out, there’s a huge need to have a clear distinction between the user preferences and the user data. This is already covered by the FreeDesktop XDG folders specification.
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).
Of course, there’s no need to read the environment variable yourself : most language provide a library to use XDG folder. For example a patch for a GTK application or one for a python application.
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,..)
GNOME projects are listed in the tracking bug and you can help to complete the Gnome goal proposition.
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.
As a writer and an engineer, I like to explore how technology impacts society. You can subscribe by email or by rss. I value privacy and never share your adress.
I write science-fiction novels in French. For Bikepunk, my new post-apocalyptic-cyclist book, my publisher is looking for contacts in other countries to distribute it in languages other than French. If you can help, contact me!