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

codesite-noreply at google.com codesite-noreply at google.com
Thu Nov 24 20:15:01 CET 2011

Comment #3 on issue 484 by wirtwo... at gmail.com: Use XDG Base Directory  

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  
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  
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  
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  
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  

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

More information about the xmonad mailing list