[xmonad] Issue 484 in xmonad: Use XDG Base Directory Specification

[codesite-noreply at google.com]

Comment #3 on issue 484 by wirtwo... at gmail.com: Use XDG Base Directory  
Specification
http://code.google.com/p/xmonad/issues/detail?id=484

For reference here are links to the previous inconclusive discussion of
a patch to implement the XDG_CONFIG_HOME portion of Issue 484. [1] [2]

If something like this is to be implemented, a good time would be just  
after a
bug fix release of 0.10. Afterward there would be plenty of time for the  
news
to get out, addressing issues it creates, and adjusting troubleshooting and
docs prior to 0.11 (or whatever it's called.)

That said, I'm in the camp that isn't yet convinced the benefits outweigh  
the
extra complications. Especially for all the non XDG_CONFIG_HOME files.

I consider this a config breaking change, since users would have to move
xmonad.hs. Supporting xdg plus ~/.xmonad to avoid breakage doesn't make  
sense
to me. Considering that the main objection to xdg support is increased
complexity, adding even more along with additional ambiguity is a bad idea.

The way I read the spec, complying would be more involved than what's being
proposed. [3] There are two additional directories to support plus a few
additional consequences.

* Moving non-essential generated files to an xdg cache directory would also
need to process lib/ and its subdirectories.

Using a cache directory wouldn't by itself prevent the upgrade issues where
the old .hi files yield confusing error messages. (These sparked the "delete
temporary files" proposals.) Deleting these files once xmonad's done with  
them
might be better than using a new cache directory.

Probably xmonad-errors should also go to the cache directory along with .hi,
.o but I'm not sure where users would expect it to live since it does give
feedback about broken configs.

* Another directory $XDG_RUNTIME_DIR should get xmonad-$arch-$os.

* $XDG_DATA_HOME should get X.Prompt's .xmonad/history and any similar  
files.

Overall, I think that to sway enough people toward favoring XDG support it's
going to take posting compelling use cases illustrating its benefits, along
with sustained lobbying over time.

[1] http://www.haskell.org/pipermail/xmonad/2008-May/005762.html

[2] http://www.haskell.org/pipermail/xmonad/2008-August/006214.html

[3] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html