The XDG spec is so simple, if a software developer still lacks the mental capacity to adhere to it he/she might be better of finding different hobbies. Come on now.
The XDG spec is so simple, if a software developer still lacks the mental capacity to adhere to it he/she might be better of finding different hobbies. Come on now.
I'm not convinced that one is unequivocally better than the other. For me personally, I prefer a flat namespace to having to hunt down directories in a tree of varying depth.
I manage $HOME, this is meant for valuable personal documents. I manage them manually. You as a software distributor better are not gonna clash with what I am doing there with your shitty engineering.
If you insist on making a mess of your $HOME, XDG allows for that. You can set all your XDG variables to $HOME. And even without doing so, you can create symlinks to make your $HOME like you want. That is an unfair advantage you get with XDG adherence.
XDG gives you as the user more control. If you don´t adhere to XDG, you take that control away from the user.
XDG allows for a superior partitioning. If you don´t like it, you are likely to complain about Linux as well. XDG separates config, run state, cache and data, which is quite reasonable for a Linux system as that is what Linux does.
---
> If I want a specific program’s config directory somewhere other than the XDG setting, that’s not possible.
1. $XDG_CONFIG_DIRS even allows for more multiple paths to be searched.
2. You could even override XDG-vars per application in a launch script or in the shortcut.
> If I want all my config, cache, and local stores in per-program directories, XDG makes that impossible.
You can set all the relevant $XDG_vars to $HOME and all your foo stuff ends up in $HOME/foo. Or symlink from $HOME.
The XDG world gives you options, while the non-XDG world doesn´t.
---
XDG could have opted for user overridable utils instead of variables. But you have already lots of options now.
That seems like it could easily lead to conflicts.
What about $HOME/Documents? But yeah, I hear you, I gave up on $HOME as my personal space, I put my stuff in /data (I use my computer alone) and let any software pollute my $HOME.
Besides, if you think that's polluted, then pushing it off to ~/.config and ~/.local/share is just sweeping it under the rug.
If you want to create a mess, you are free to do so with XDG variables. Read my other comments for that.
Stop pissing in my $HOME and don´t tell me I should have no problem with that. Just adhere to XDG, $HOME is for me and I decide what I want there. You don´t.
If you want to shit around in $HOME, you can make symlinks from $HOME or set your XDG-vars to $HOME.
In the non-XDG world we don´t have that control. Such software shits into $HOME, and it sticks there because it refuses to listen for user preferences (XDG-vars). As a user that deals with non-xdg software I don´t have control on the one directory that was meant for ME.
--
The only improvement I can think of is that XDG would provide functions that software could call into instead of vars to get dir paths. That way, the user could have very fine control (even per application) when they write their own bash override.
> If I want .chromium, .0ad, etc. instead of .config, I'm SOL.
Technically not SOL, you just need to set the launcher of whatever binary to set the XDG env vars to $HOME/.programname on launch.
Or use links.