Summary: | Under Windows KDE Application configuration files must be stored in %APPDATA% not in %LOCALAPPDATA% | ||
---|---|---|---|
Product: | [Frameworks and Libraries] frameworks-kxmlgui | Reporter: | Thomas Debesse <dev> |
Component: | general | Assignee: | kdelibs bugs <kdelibs-bugs> |
Status: | REPORTED --- | ||
Severity: | normal | CC: | caulier.gilles, paul.hervin |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Microsoft Windows | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Bug Depends on: | |||
Bug Blocks: | 382363 |
Description
Thomas Debesse
2017-07-15 04:12:21 UTC
See #382363 for the special case of `digikam\template.xml`. linking bug 382363 Note that I noticed `showfoto` and `kdenlive` on windows are affected too. Do I have to open a bug for each software affected by this bug? This is probably a bug in a common component. It's a bug in common component from KDE library : KF5::KXMLGUI our KConfig, i'm not 100% sure. I forward to KDE core team for analyze. Gilles Caulier I confirm that bug also affects Krita, it's obiously a bug in a common component! A quick lookup reveals many stuff in the whole kde tree uses `QStandardPaths::DataLocation` (which returns `%LocalAppData%` as `QStandardPaths::AppLocalDataLocation` does) or even `QStandardPaths::GenericDataLocation` that does exactly the same (and some code also uses %LocalAppData% directly) instead of `QStandardPaths::DataLocation` that returns %AppData% (added in Qt 5.4) which is the only viable option. As read there: https://doc-snapshots.qt.io/qt5-dev/qstandardpaths.html > QStandardPaths::DataLocation > Returns the same value as AppLocalDataLocation. This enumeration value is deprecated. Using AppDataLocation is preferable since on Windows, the roaming path is recommended. > QStandardPaths::AppDataLocation > Returns a directory location where persistent application data can be stored. This is an application-specific directory. To obtain a path to store data to be shared with other applications, use QStandardPaths::GenericDataLocation. The returned path is never empty. On the Windows operating system, this returns the roaming path. This enum value was added in Qt 5.4. I would said that on Windows using `AppDataLocation` is not only recommended but required since other options (DataLocation, GenericDataLocation, AppLocalDataLocation) return a directory designed to be local to a disposable computer and to not be part of the user's profile. This directory is made to be not be shared among multiple computers, to not be backed up and to be wiped out. It's a bit like writing user's configuration in /temp: it's definitely not a place to save user's configuration. *** Bug 402346 has been marked as a duplicate of this bug. *** Bug 402346 is not a duplicate of this. Bug 402346 is saying that digikamrc must be stored withing a digikam/ directoy whatever the parent directory is, this issue is saying the parent directory is wrong. Perhaps Qt documentation has to be edited to say:
> Beware: `QStandardPaths::DataLocation` is not doing what you think it is
QStandardPaths::DataLocation never returns the DataLocation, it returns a Local Cache Location.
The real DataLocation is given by QStandardPaths::AppDataLocation.
For storing disposable local (to the machine) cache, software can use QStandardPaths::AppLocalDataLocation. QStandardPaths::DataLocation seems to be there just because of history, it mistakenly calls to QStandardPaths::AppLocalDataLocation which is wrong and is not what developer expects.
|