41–50 of 223 posts
This is a recurring pattern that systemd documentation is sold as "neutral" standard. The UAPI group is another example of this.
It seems like the best of both worlds, here, would be to put the files in ~/.config/yourprogram, and symlink that to `~/Library/Application Support/org.example.yourprogram`. That would satisfy folks expecting to find it in either place. The only folks it wouldn't satisfy would be those complaining about the files being present in one of those places at all, and that seems like the least of the concerns compared to ma…
> But suppose we accept that the XDG specification only applies to some Unix operating systems, despite making no mention of this. the very first paragraphs on specifications.freedesktop.org says this: > Freedesktop.org is a project to work on interoperability and shared base technology for free-software desktop environments for the X Window System (X11) and Wayland on Linux and other Unix-like operating systems. > W…
The issue is that often everyone assumes that XDG_CONFIG_HOME is ~/.config
The idea of having a variable is that it could be anywhere,
I wrote elsewhere that I think the solution to this is to add another variable to the XDG Base Directory Specification to explicitly opt into using XDG variables, and then to support that flag on libraries that target Windows / MacOS and which would otherwise choose mac Application Support / Windows AppData folders.
Both options are wrong on macOS. My configurations are preferences , stored in ~/Library/Preferences. Even better if you store those as property lists and hook into CFPreferences so I can manage them with configuration profiles and use the defaults command to query and modify my preferences without having to open the app or read some 4000 line long JSONC file with 20 lines of settings and ~4000 lines of bad documenta…
> This directory contains app-specific preference files. You should not create files in this directory yourself.
Also
> defaults command to query and modify my preferences without having to open the app or read some 4000 line long JSONC file with 20 lines of settings and ~4000 lines of bad documentation.
I'd prefer the convenience of an editor to read the real 5 lines and 5 lines of comments of the settings I've changed (instead of the made up 4000000) and having a diffable config rather than some binary plist nonsense and relying on a clunky defaults cli. I'd even be prepared to shed the complexity of profiles for this basic conveniences
I and others have brought this up with the dirs Rust crate maintainer but they refuse to see it this way: https://codeberg.org/dirs/dirs-rs/issues/64 . It's very frustrating. I now use a combination of xdg + known-folders manually: [target.'cfg(windows)'.dependencies] known-folders = "1.2.0" [target.'cfg(not(windows))'.dependencies] xdg = "2.5.2" to get the config directory: use anyhow::{Context, Result}; #[cfg(windo…
Why is that soc guy so angry and rude about it?
My personal practice when writing command line utiities for macOS is to use the macOS API to write settings (previously known as “preferences”) into ~/Library/Preferences, so they can interoperate with any GUI versions of them I might like to write, and for the utilities themselves to have command line options to control those settings. As a sibling comment suggests, you do need to avoid name space collisions. You can use a reverse DNS name, or some companies are big enough just to use their company name. They do appear as .plist files but are actually maintained by a daemon – which nicely avoids race problems with multiple processes updating settings.
If I were writing a portable utility which had a dotfile with a documented format the user was expected to edit, I would make it a dotfile under the home directory.
~/Library/Application Support is really more for per-user static data, like presets and templates, things that are known in a GUI by a string in some dialogue but not necessarily thought of by the user as a file.
Earlier quoted context omitted.
Why is that soc guy so angry and rude about it?
Certainly doesn't make me want to become a Rust contributors.
I and others have brought this up with the dirs Rust crate maintainer but they refuse to see it this way: https://codeberg.org/dirs/dirs-rs/issues/64 . It's very frustrating. I now use a combination of xdg + known-folders manually: [target.'cfg(windows)'.dependencies] known-folders = "1.2.0" [target.'cfg(not(windows))'.dependencies] xdg = "2.5.2" to get the config directory: use anyhow::{Context, Result}; #[cfg(windo…
but CLI tools are applications
I and others have brought this up with the dirs Rust crate maintainer but they refuse to see it this way: https://codeberg.org/dirs/dirs-rs/issues/64 . It's very frustrating. I now use a combination of xdg + known-folders manually: [target.'cfg(windows)'.dependencies] known-folders = "1.2.0" [target.'cfg(not(windows))'.dependencies] xdg = "2.5.2" to get the config directory: use anyhow::{Context, Result}; #[cfg(windo…
Why is that soc guy so angry and rude about it?