[dead]
Use the XDG Base Directory Specification
201–210 of 214 posts
Re: Use the XDG Base Directory Specification
#202Earlier quoted context omitted.
So that's not any fault of XDG, that's you forcing applications to use it when they apparently don't support it natively. That's either 15 or 19 lines of application bugs.
Reread what I said, "apps should just use xdg out of the box"
No, you said "when your xdg list gets huge, apps should just use xdg out of the box". But the link you shared shows only 4 lines in your xdg list. 4 lines is hardly huge.
Re: Use the XDG Base Directory Specification
#203Earlier quoted context omitted.
> But they don't seem to care While I've not fully dug into all of those links, that is rarely the case and it makes the conversations harder when people over simplify situations like this. Generally, I've found when people make assumptions like this, the underlying requirements are a lot more involved and its not a high enough priority for the small group of overtaxed individuals.
You're right. I apologize. The fact that there was a PR actually shows that some people care.
There are 200 thumbs up? And a lot of those are rust people who care.
Re: Use the XDG Base Directory Specification
#204Somebody should tell that to the Rust people. They have a .cargo and a .rustup folder in ~, plus an extra heavy target folder for every project. Would be much nicer if they put the cache one .cache But they don't seem to care https://github.com/rust-lang/cargo/issues/1734 https://github.com/rust-lang/rfcs/pull/1615 https://github.com/rust-lang/cargo/pull/9178
> But they don't seem to care While I've not fully dug into all of those links, that is rarely the case and it makes the conversations harder when people over simplify situations like this. Generally, I've found when people make assumptions like this, the underlying requirements are a lot more involved and its not a high enough priority for the small group of overtaxed individuals.
Rust postponed this feature in the RFC process. https://github.com/rust-lang/rfcs/pull/1615
So it's been through some official channels.
Re: Use the XDG Base Directory Specification
#205Earlier quoted context omitted.
> Easier to create backups i want to mess up with wine, now I just backup ~/.wine, do whatever, restore. With split folders, i'd have to backup a bunch of folders (.config/wine, .local/share/wine, .local/lib/wine or wherever the files, registry, dosdevices and other stuff would be put).
> i want to mess up with wine, now I just backup ~/.wine, do whatever, restore. You can set WINEPREFIX to use a non-default prefix path (other than `~/.wine`). Note that the prefix doesn't contain everything that wine spills all over your home. It adds (XDG `.desktop`) launchers & menu/desktop shortcuts, file type associations, icons, etc. to the usual locations.
Usually I need to upgrade something within a wine environment, and sometimes the new version of whatever software doesn't work, so "cp -r .wine .wine-bak", do whatever, fail, rm, cp back, and it's done.
Re: Use the XDG Base Directory Specification
#206Earlier quoted context omitted.
Reread what I said, "apps should just use xdg out of the box"
No, you said "when your xdg list gets huge, apps should just use xdg out of the box". But the link you shared shows only 4 lines in your xdg list. 4 lines is hardly huge.
Why should I have to maintain a list of applications that don't conform to the standard? I tried to, and the list keeps growing. I'm done screwing around with it, I don't care how cluttered my homedir gets anymore.
Re: Use the XDG Base Directory Specification
#207Earlier quoted context omitted.
That has never been a standard as many programs have multiple dotfiles in ~. But even if it was, there are still good arguments for the XDG Basedir Spec: common way to change the location via environement variables as well as ability to split cache and non-cache.
Having this depend on env vars is an anti-feature in my mind. It's much harder to ensure env vars are set to the "right" values in all situations then it is to just use some well-known paths.
Come on, you just use a fallback if it's unset, you can even use your "well-known" paths for that if you want to. Don't pretend this harder than it actually is! This is like lesson 1 to using environmental variables, it's like saying you never free your mallocs because it's "much harder" that way! The OP site even provides code examples for popular languages, how can you imply that randomly littering your user's $HOME directory is the viable alternative here?
Re: Use the XDG Base Directory Specification
#208I have a very dumb question: why does the article use `find` with `printf` and depth specification, as opposed to the simpler `ls -a`? I'm assuming it has something to do with portability, but `ls -a` is already in POSIX. I'm a bit confused.
Re: Use the XDG Base Directory Specification
#209Oh I‘m fighting the battle for a clean home directory for years. I even use a setup on macOS to set specific environment variables via systemd during login so I can link them into the .config directory. Only issue with my setup in general is that I can‘t just replicate it for other people. I moved .aws directory in .config/aws and I sometimes forget what the default for most tools is or where I helped the tool out to…
macOS + systemd? If on Linux this tool allows you to move config dir and file locations transparently. Pretty neat. https://github.com/queer/boxxy
Nice. Thanks for that.
This is my launch agent. https://github.com/Larusso/dotfiles/blob/master/.config/yadm... The nice side effect is that Apps launched via Spotlight will also inherit the path etc since they all are owned by launchd in the end.
Re: Use the XDG Base Directory Specification
#210Earlier quoted context omitted.
macOS + systemd? If on Linux this tool allows you to move config dir and file locations transparently. Pretty neat. https://github.com/queer/boxxy
Nice. Thanks for that. This is my launch agent. https://github.com/Larusso/dotfiles/blob/master/.config/yadm... The nice side effect is that Apps launched via Spotlight will also inherit the path etc since they all are owned by launchd in the end.
Edit: Sorry for the confusion with systemd I meant launchd. I always mix these up.