Using XDG-Compliant Config Files (2024)
wxwidgets.org
wxwidgets.org
If you have the files in the XDG locations and symbolic links in the old locations, this migration mechanism will mess things up quite badly, because it does not check for either symbolic or normal links and renames over the XDG file if an old location file exists.
The model here seems to be that configuration files are entirely under application control, and users do not go around manually creating them, changing them, or creating compatibility symbolic links. Which really does make a nonsense of using an INI variant as the configuration file format. One might as well make it easily machine readable if humans are never meant to be touching it.
But then this library has old design written all over it, once one looks at it with a Windows developer hat on. It claims to place global INI files in the Windows directory, something that has been deprecated in Windows for over 30 years. Although, just to make things interesting, that documentation does not describe what the code nowadays does.
* https://github.com/wxWidgets/wxWidgets/blob/master/include/w...
likewise for ~/.cache ($XDG_CACHE_HOME). does wxWindows provide a cross platform abstraction for the cache dir, too?
This is a different problem than migrating file locations in the same OS, as what the linked blog post is about, but it is a related issue for apps intending to be multi-platform.
Who do they think defined this standard, if not the people who had "been around even longer".
IIRC KDE was first with cleaning up the clutter by hiding things in ~/.kde or something like that, but there's a ton of config/bookmarks/menus/data/caches you want to everything to use, so it was a given that there would be some standardization.