https://bugs.kde.org/show_bug.cgi?id=402346
--- Comment #14 from Thomas Debesse <d...@illwieckz.net> --- `GenericConfigLocation` should never be used to store configuration. On Windows it is set to `C:/Users/<USER>/AppData/Local`, here `Local` means “local to the machine”. This being “local” means anything stored here is lost when the computer is replaced and such data is not meant to be backed up. It's only use is for some machine-specific data. This is the place to store data that is not cache but should not be backed up. The only situation where a configuration can be placed there, is like if the configuration is specific to the hardware and is not supposed to be reusable on another hardware (like some screen layout on a laptop). The application configuration should be stored in `AppDataLocation` which is `C:/Users/<USER>/AppData/Roaming/<APPNAME>` on Windows. The application configuration should be stored in the “Roaming” folder, never the “Local” one. As said the Local one is meant to be lost with the computer, the Roaming one is the one that is kept is sync with the file server. If a computer breaks, the IT service just replaces the computer and on next session opening, the “Roaming” server is downloaded and the user gets his config restored on the new computer like if nothing happened. The same happen in an office with multiple desks that are not specific to users: whatever the computer the user uses, the Roaming folder will be kept in sync with the computer he logs on (hence the “Roaming” name), whatever the computer. If the configuration is stored in the “Local” folder, then the user will have to reconfigure the software on every workstation as the user roam across the various workstation according to workstation availability. The `GenericConfigLocation` has almost no usage, there is a reason why `GenericCacheLocation` is set to `C:/Users/<USER>/AppData/Local/cache` on Windows, because the Local folder is local to the machine, but setting generic configuration in Local folder is nonsensical, the only situation where config can be stored here is that if the config is non generic but local, specific to the exact computer and assumed to be non-portable across computers. The `GenericConfigLocation` being set to `C:/Users/<USER>/AppData/Local/` on Windows is a design bug of Qt itself. Qt applications should use `<GenericConfigLocation>/<APPNAME>` on everything but Windows, but should use `AppDataLocation` on Windows. The confusion is that file layouts totally doesn't match between Windows and Linux. On Linux there is a separation between `<HOME>/.config/<APPNAME>` (application config directory) `<HOME>/.local/share/<APPNAME>` (data application directory). On Windows that doesn't exist, there is only `<DRIVE>\Users\AppData\Roaming\<APPNAME>`. On the other hand, while Windows has both a “Local” local-to-the-machine folder and “Roaming” shared-accross-machines folder, Linux doesn't have such distinction: everything is part of the same home folder and is backed up. The “Local” name in Windows and the incredibly misnamed “.local/share” folder on Linux adds to the confusion, the Windows “Local” folder is “local to the machine”, the Linux “.local” folder is just a parent folder with weird name for the “share” folder and maybe no other folder. The “share” name of a folder purposed to be shared is antinomic with its parent ”local” one as it is not local but shared. Maybe XDG designers just wanted to somewhat mimic the File Hierarchy Standard with user's `.local/share` being like system's `/etc/share` and maybe some other future `.local/something`. Anyway, NEVER use Qt's GenericConfigLocation to store application configuration on Windows : this is a serious mistake, it's the same mistake as writing configuration in a cache folder. -- You are receiving this mail because: You are watching all bug changes.
