On Oct 30, 2009 I wrote Using XDG folders, on the subject of Sundry Hacks and Linux.

Lionel's just written about how applications should use the FreeDesktop ("xdg") folders. I like this a lot more than most people do, because my XDG folders aren't the default. The default folders are .local/share, .config, and .cache. Now, to me, having my settings be in an invisible folder defeats the point. So my folders are Applications/Data, Applications/Settings, and Applications/Cache. The beauty of this is that if an app has gone mad, I can just go into Applications/Settings, find the settings file or folder for an app, and delete it. No grovelling around on the command line. It's lovely. To do it, put this in .gnomerc*:

#!/bin/bash
export XDG_DATA_HOME=$HOME/Applications/Data
export XDG_CONFIG_HOME=$HOME/Applications/Settings
export XDG_CACHE_HOME=$HOME/Applications/Cache

and then all proper applications just store their data in there. Couple of other tiny benefits: it's easy to see what you've got installed, and it's also to see which naughty applications don't actually check what your XDG folders are and just hardcode the defaults into their program (notify-osd, I'm looking at you here, and whatever stores motd.legal-displayed as well).

Cyril

Wouldn't it be simpler if everything was *STEP-like?

Jonathan Doyle

How is this any different from doing Ctrl+H in Nautilus and then going to .local/share or .config or .cache whenever you need to?

Also, these are folders I hardly use so what's the point in cluttering my home directory with some extra folder that I'd rarely use?

sil

Cyril: no idea. I don't know how Nextstep worked.

Jonathan: ah, OK. I find myself casting out an application's settings to refresh it, or looking at an application's data, quite a lot. If you don't, then obviously hiding them is the way to go. However, making them visible gives discoverability to people who aren't as techie as us and therefore don't know where to look for this data. I quite like the idea of switching the default to be visible folders, and then people like us can have the knowledge to make them invisible if we want.

randomdev

Jonathan: The point is, if applications use these environment variables, each individual can decide what they prefer. Hardcoding such directory paths is just nasty.

> I find myself casting out an application’s settings to

> refresh it, or looking at an application’s data, quite a lot

Funny, given that you're working on Desktop Couch, which makes this sort of thing less straightforward (despite the web UI and API)...

(Not criticizing, just observing.)

artir

You should consider making that default for Lucid

(I mean .Applications/*) to store all the configuration and clean the dot-directories clutter we have in /home

hewbass

I _think_ that to get this working generally for X, you would want to put this in a file like $HOME/.xsession.

I say I _think_ because the last time I tried this I broke X, so YMMV.

sil

randomdev: ah, settings and data folders only allow me to interact with my applications' data in a very high-level way - if I see an Applications/Data/myapp file, I can remove it, but I can't edit it because I don't know which format it's in -xml,ini, json, sqlite, etc. That's one of the issues that desktopcouch is alleviating. I'd like to see apps store a hyperlink to their config data in the xdg folder, though. Good idea.

randomdev

> I can’t edit it because I don’t know which format it’s in

I don't necessarily agree with this - as long as it's plain text, the structure is generally easy to deduce, without requiring another layer of abstraction.

However, I do agree that data stored in formats like SQLite might just as well be in Desktop Couch.

> I’d like to see apps store a hyperlink to their config

> data in the xdg folder, though.

That's a nice idea indeed!

Sense Hofstede

I Confirmed the bug you reported and requested a merge request for a branch I created afterwards containing the fix. I expect we'll have to wait until the work week starts again Monday before someone will have a look at it, but until then you can always use the code from , it should work flawlessly.

Sense Hofstede

I've filed a bug in base-utils [1] concerning the motd.legal-displayed file in .cache. Unfortunately the code of base-files isn't available on Launchpad, but from what I've seen in mailist archives it seems like .cache is hardcoded here as well.

[1] https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/467300

James

"However, making them visible gives discoverability to people who aren’t as techie as us and therefore don’t know where to look for this data. I quite like the idea of switching the default to be visible folders, and then people like us can have the knowledge to make them invisible if we want."

Do you really think a non-techie will know how to do anything useful with even plaintext config files? These things scare people. There's a reason why every popular desktop environment on the planet abstracts configuration through graphical control panels.

James

(Offplanet desktop environments could not be examined for configuration usability ;-)

sil

James: the thing that people can do with config files is delete them to see if it fixes the problem.

David

@sil (all comments): Exactly.

And, in an ideal document-centric world, those config files would be neatly organized and named, and opening an application’s configuration file would actually launch its corresponding preference dialogue. Thus, ideally, every window would map directly onto a file—even preference windows. Of course, deleting a config file (or even reverting it) should also be as easy as doing so to any other file. Ah, to dream…