Hopefully the migration function doesn't silently move files. If you have dotfile symlinks, those would need updating. Also it would be surprising if config files were in a new place one day.
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.
Genuinely curious- what would the cross platform compatibility help with? Ease of migration? I don't remember configuring many win programs with notation like such, just the PATH
There are Qt analogs for just this thing (QStandardPaths, https://doc.qt.io/qt-6/qstandardpaths.html) to drastically simplify what can be a quite annoying task if you're trying to write GUI software that respects the OS standard file locations across multiple desktops.
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.
> XDG Base Directory Specification has been a standard for organizing application data files under Linux for a long time. Unfortunately, wxWidgets has been around for even longer, and when support for configuration files was added to it back in 1997, the usual convention was still to put these so-called “dot files” directly in the user home directory
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.
I'm on KDE 6, and I don't have a ~/.kde. I think now a days, KDE uses ~/.config and ~/.local/share. Honestly, sometimes I wish the KDE Frameworks had a thing like Dconf, so apps can store their configurations inside of a database instead of barfing everything out into a ~/.config folder.
Hopefully the migration function doesn't silently move files. If you have dotfile symlinks, those would need updating. Also it would be surprising if config files were in a new place one day.
From inspection of the code:
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...
is this aspect also cross platform? like supporting Windows %APPDATA% and %LOCALAPPDATA% ?
likewise for ~/.cache ($XDG_CACHE_HOME). does wxWindows provide a cross platform abstraction for the cache dir, too?
Genuinely curious- what would the cross platform compatibility help with? Ease of migration? I don't remember configuring many win programs with notation like such, just the PATH
There are Qt analogs for just this thing (QStandardPaths, https://doc.qt.io/qt-6/qstandardpaths.html) to drastically simplify what can be a quite annoying task if you're trying to write GUI software that respects the OS standard file locations across multiple desktops.
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.
Appreciate the insight
> XDG Base Directory Specification has been a standard for organizing application data files under Linux for a long time. Unfortunately, wxWidgets has been around for even longer, and when support for configuration files was added to it back in 1997, the usual convention was still to put these so-called “dot files” directly in the user home directory
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.
I'm on KDE 6, and I don't have a ~/.kde. I think now a days, KDE uses ~/.config and ~/.local/share. Honestly, sometimes I wish the KDE Frameworks had a thing like Dconf, so apps can store their configurations inside of a database instead of barfing everything out into a ~/.config folder.
KDE 3 and 4 used a ~/.kde or similar. They moved it all to XDG-compliance with KDE 5.
Great for apps, terrible for people. It's much simpler to sync setups across machines with plain files than databases.
What is your point here?