My fellow software engineer, It's the year 2024...
My fellow software engineer, It's the year 2024...
Attached: 1 image My fellow software engineer, It's the year 2024. Please store your #Linux #desktop application configurations ONLY in `$XDG_CONFIG_HOME`. NOT in `$HOME` or other non-standard or obsolete places. May #FreeDesktop be your guide. https://www.freedesktop.org/wiki/Specifications/...
Shameless plug: I am the author.
You're viewing a single thread.
This would just further complicate things for me. It assumes that 1) the system even has a windowing system/desktop environment or 2) all the installed software is XDG-aware. Most of the time I’m fiddling with headless environments.
It's not too hard to check for XDG support first and use a few hardcoded directory paths if that is unavailable.
It’s even easier to ignore it altogether, which is what I do. I don’t use “a few” non-XDG-aware things; I use lots an lots of them.
Are you saying that you don't want to write your software according to the XDG spec, or that you don't want to set the XDG env vars on your system? If it's the second that's fine - apps using XDG work just fine if you ignore it. If it's the first I'd suggest reconsidering because XDG can make things much easier for users of your software who have system setups or preferences that are different from yours; and using XDG doesn't cause problems for users who ignore it.
OP's recommendation is aimed mostly at software authors.
I meant the second. But as to the first: I generally write in-house software for headless server environments, and my peers are going to push back if I add irrelevant XDG foo to my PR.
So yes, "XDG" stands for "Cross-Desktop Group" - but I don't agree that using the spec assumes a windowing system. The base directory spec involves checking for certain environment variables for guidance on where to put files, and falling back to certain defaults if those variables are not set. It works fine on headless systems, and on systems that are not XDG-aware (I suppose that means systems that don't set the relevant env vars).
OTOH as another commenter pointed out the base directory spec can make software work when it otherwise wouldn't on a system that doesn't have a typical home directory layout or permissions.
The spec doesn't make those assumptions at all, idk where that's coming from.