Use XDG Base Directory Specification

[GoogleCodeExporter]

Hello,

Would it be possible to make xmonad respect the XDG Base Directory [1] 
specification? This would allow the user's home directory to be more organized 
and clearly separate configuration files, cache files and user data.

For xmonad the following changes would be necessary:
- move ~/.xmonad/xmonad.hs to $XDG_CONFIG_HOME/xmonad/xmonad.hs
- move other generated files (like xmonad.hi) to $XDG_CACHE_HOME/xmonad/

Thanks in advance,
Cristian KLEIN.

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

Original issue reported on code.google.com by cristikl...@gmail.com on 24 Nov 2011 at 9:42

[GoogleCodeExporter]

Backward compatibility would be a beast.

Original comment by allber...@gmail.com on 24 Nov 2011 at 6:45

[GoogleCodeExporter]

This has been suggested and patched before: 
http://www.haskell.org/pipermail/xmonad/2008-May/thread.html#5762

Spencer's opposition (scroll down): 
http://www.haskell.org/pipermail/xmonad/2008-August/006214.html 
http://www.haskell.org/pipermail/xmonad/2008-September/006253.html

I don't think his criticisms were rebutted, but you can try.

Original comment by gwe...@gmail.com on 24 Nov 2011 at 7:01

[GoogleCodeExporter]

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

Original comment by wirtwo...@gmail.com on 24 Nov 2011 at 7:13

[GoogleCodeExporter]

This is also tied into the Dyre discussions 
(https://code.google.com/p/xmonad/issues/detail?id=350&q=dyre and misc email); 
Dyre by default, IIRC, uses an XDG-layout. Will *has* been maintaining Dyre up 
to 2011 and the latest release still builds, but so far there's been no real 
pressure to move to it.

Original comment by gwe...@gmail.com on 24 Nov 2011 at 7:25

[GoogleCodeExporter]

I am also interested in having xmonad obey the XDG specification.

Original comment by david.lazar on 10 Feb 2013 at 9:30

[GoogleCodeExporter]

Also reported as http://bugs.debian.org/719857

Original comment by nome...@gmail.com on 16 Aug 2013 at 8:55

[GoogleCodeExporter]

I created a patch that prefers the XDG Base Directory specified directories 
over ~/.xmonad.

I grep'ed for xmonad.hs in the XMonadContrib repository and could only see 
occurrences in the documentation, so it should not break anything. (I may have 
missed a line, though!)

Original comment by woozlet...@gmail.com on 21 Nov 2013 at 9:15

[GoogleCodeExporter]

Shame on me! I overlooked the Main.hs and haven't cleaned my config directories 
properly. 
The attached patch is pretty much the same as before, but with the necessary 
changes included in the Main.hs file.

Greetings
saep

Original comment by woozlet...@gmail.com on 22 Nov 2013 at 7:53

[GoogleCodeExporter]

I start to feel stupid, but just to provide a more solid base for a discussion 
on how one could handle the XDG Base Directory specification. I fixed an issue 
in the following path that occured if the $XDG_CACHE_HOME/xmonad directory did 
not exist.

Sorry for the spam!
saep

Original comment by woozlet...@gmail.com on 24 Nov 2013 at 5:06

Attachments:

• xdg.dpatch

[GoogleCodeExporter]

Any update on this?

Original comment by methe...@gmail.com on 18 Oct 2014 at 10:03

[GoogleCodeExporter]

I have written a patch for using an environment variable to configure the 
base-directory of xmonad. See 
http://www.haskell.org/pipermail/xmonad/2014-October/014339.html.

e.g. if you start xmonad with the environment-variable:
$ export XMONAD_WORKING_DIR_NAME=$XDG_DATA_HOME && xmonad
the directory in XDG_DATA_HOME will be used.

There is also a discussion about the XDB directory in the directory package. 
https://ghc.haskell.org/trac/ghc/ticket/5966
https://github.com/haskell/directory/issues/6

IMHO we should wait for the result of the discussion in the directory package. 
Maybe there is nothing to do after that discussion for this issue. 

Original comment by oliver.d...@gmail.com on 25 Oct 2014 at 6:40

[GoogleCodeExporter]

Concerning comment #11 about moving everything from ~/.xmonad to 
$XMONAD_WORKING_DIR_NAME: putting everything in another directory is not enough 
to conform to the basedir spec. Considerations include (but may not be limited 
to) the concerns raised in comment #3.

Original comment by daniel.w...@gmail.com on 26 Oct 2014 at 3:06

[GoogleCodeExporter]

@ #12: I know that this solution is only a part of the XDG specifications. This 
patch is only for using a different directory for the config file no mather if 
it uses the XDG spec or not. 

Depending on the discussion how to implement XDG based directories in the 
library 'directory' there is also some work todo here. My intention was to wait 
for the result of the discussion and use that patch for different config 
directories in the meantime.

Original comment by oliver.d...@gmail.com on 27 Oct 2014 at 8:52

[GoogleCodeExporter]

I am opposed to xmonad moving to an XDG-style file layout. XDG is a nice 
standard for non-Windows OSes that want to provide a legacy Windows-like 
experience. But I am using xmonad exactly because I want to get away from that. 
I want something lighter, more elegant, easier to work with using Unix 
principles.

But I am certainly not opposed to xmonad providing XDG compliance when an 
environment variable is set, for those who do want that - along the lines of 
what Oliver did.

Original comment by sefer....@gmail.com on 28 Oct 2014 at 9:19

[GoogleCodeExporter]

Using XDG Base Directory specs is being a good citizen. Its a simple spec with 
defined criteria and is as simple as using filepaths from environment variable 
values and using predetermed defaults otherwise. Most programming languages 
have a small package available to implement it.

It applies the spirit of the GNU filesystem heirarchy to your home and user 
directories.

Original comment by enm...@gmail.com on 28 Oct 2014 at 11:03

[GoogleCodeExporter]

Most people using xmonad are trying to get away from overgrown GNU/Gnome stuff 
--- and it is worth remembering that xmonad was developed on NetBSD, not Linux.

Also, if you are going to do XDG directories, please do them correctly. No, 
it's not appropriate to claim XDG compliance if you're just glopping everything 
into some random different path instead of splitting things up the way the XDG 
spec *for good reason* specifies.

Original comment by allber...@gmail.com on 28 Oct 2014 at 11:24

[GoogleCodeExporter]

fyi,  xdg spec is not GNU or GNOME specific in any way.  Lots of command line 
programs and cross platform non-desktop programs comply with it just fine.  
Agreed on doing it properly however.

Original comment by methe...@gmail.com on 29 Oct 2014 at 10:07

[GoogleCodeExporter]

XDG started out as part of Gnome and KDE reconciling their desktops, with Gnome 
mostly winning.

Original comment by allber...@gmail.com on 29 Oct 2014 at 12:57

[GoogleCodeExporter]

that tidbit is not relevant for xdg base dir spec as it stands now which has 
wide support far beyond desktop environments. 

Original comment by methe...@gmail.com on 29 Oct 2014 at 1:26