SUMMARY The digikamrc file is not recorded into the digikam directory STEPS TO REPRODUCE 1. Install fresh digikam 2. Launch digikam, then quit. 3. OBSERVED RESULT The digikamrc file is recorded into the %localappdata% directory. EXPECTED RESULT The digikamrc file should be recorded into the %localappdata%/digikam directory. SOFTWARE/OS VERSIONS Windows: 7 MacOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Please provide the resource moving at the upgrade to fixed version.
This also applies to other ported programs, e.g. Krita. A system component sets this path. Maik *** This bug has been marked as a duplicate of bug 382358 ***
Note that the right path to store this file must not be %LOCALAPPDATA%/digikam but must be %APPDATA%/digikam In fact, KDE inherits a Qt bug: %LOCALAPPDATA% is a directory that is local to a machine, it's meant for local cache and is disposable. %APPDATA% is the user directory that is kept whatever the machine it uses. In a network-based environment, where the user is working on a network domain, %APPDATA% roams across the machines, %LOCALAPPDATA% not. %LOCALAPPDATA% must not be used for configuration since the user can't read the configuration when he connects from another computer or replace its computer (or if an hardware failure occurs).
This is not a duplicate of Bug 382358. This bug is reporting that digikamrc file must be stored as: <something>/digikam/digikamrc instead of: <something>/digkamrc Bug 382358 is reporting that <something> must be: %APPDATA% instead of: %LOCALAPPDATA%
*** Bug 413489 has been marked as a duplicate of this bug. ***
We have updated whole Qt to last 5.14 and KF5 to 5.65. Both are responsible of application settings management. Can you reproduce the problem with digiKam 7.0.0-beta2 pre release ? https://files.kde.org/digikam/ Thanks in advance Gilles Caulier
(In reply to caulier.gilles from comment #6) > We have updated whole Qt to last 5.14 and KF5 to 5.65. Both are responsible > of > application settings management. > > Can you reproduce the problem with digiKam 7.0.0-beta2 pre release ? > > https://files.kde.org/digikam/ > > Thanks in advance > > Gilles Caulier With the 7.0.0-beta2 pre release the digikamrc file is still stored in the %APPLOCALDATA% directory.
(In reply to Loukournan29 from comment #7) I want to precise that the %APPLOCALDATA%/digikam directory is created by the installation, but the digikamrc file is not stored in.
This is not a digiKam bug. As Maik said, Krita has also the dysfunction. Probably other KDE application ported to Windows has the same problem. As i already said, the common software component used by all KDE application is KF5::KxmlGui. This components as the rules to store configuration files at the place on operating system. There is no code like this in DK. Even if this bug is not really a dupplicates of bug #382358, this revelate a problem outside digiKam. It's clear... Gilles Caulier
https://bugs.kde.org/show_bug.cgi?id=413489 Just adding this info. Did a fresh installation of digikam 7.0.0. And the location of the digikamrc file is still there, where it always was, in the 'wrong' location. ☻ ! C:\Users\[user name]\Appdata\Local ! And not in something like: C:\Users\[user name]\AppData\Local\digikam or C:\Users\[user name]\AppData\Roaming\digikam OBSERVED RESULT wrong location EXPECTED RESULT To reside in the logical and expected directory. SOFTWARE/OS VERSIONS Windows: Microsoft Windows [Version 10 Pro 2004 19041.388]
*** Bug 452454 has been marked as a duplicate of this bug. ***
@Loukournan29, This problem still reproducible with the new digiKam 8.2.0 pre-release Windows installer available at usual place: https://files.kde.org/digikam/ This new bundle is based on last Qt framework 5.15.11 and KDE framework 5.110. Thanks in advance Gilles Caulier
Gilles and Maik, Should we be using QStandardPaths::AppConfigLocation instead of QStandardPaths::GenericConfigLocation? From the Qt docs: > QStandardPaths::GenericConfigLocation Returns a directory location where user-specific configuration files shared between multiple applications should be written. This is a generic value and the returned path is never empty. > QStandardPaths::AppConfigLocation Returns a directory location where user-specific configuration files should be written. This is an application-specific directory, and the returned path is never empty. This enum value was added in Qt 5.5. https://doc.qt.io/qt-6/qstandardpaths.html We could easily add some code to check for the old config file location and move it when people upgrade.
`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.
The `AppConfigLocation` folder should not be used on Windows either, for the same reason. Because on Windows,`AppConfigLocation` (C:/Users/<USER>/AppData/Local/<APPNAME>) is a subfolder of `GenericConfigLocation` (C:/Users/<USER>/AppData/Local>), it is not usable on Windows to store application configuration here (despite its name). This is a Qt design bug. I repeat, both `GenericConfigLocation` and `AppConfigLocation` should NEVER be used to store KDE application configuration on Windows, because on Windows this folder is meant to BE DISPOSABLE, to NOT BE BACKED UP, and to BE LOST. I mentioned it in 2018 in Comment 3. This question is already answered.
See Bug 382358 from 2017 for details about why `AppConfigLocation` and `AppConfigLocation` should never be used on Windows to store application configuration. At the time of the report, the config file was subject to both bugs, the present one (not stored in digiKam folder), and the 382358 one (digiKam folder stored in a disposable place). I currently am not available to test if both bugs are present in digiKam), but I guess they are since both bugs are open and one is related to a bug in Qt itself.
Thanks Thomas for this very well explained details about the diff between Linux and Windows. We don't change anything in the digiKam code as the KDE framework, which be used by digiKam in the background, doen't change it yet in prior. Both rules must be changed at the same time, else the application will not work at all, or, will be faced by severe regressions. To resume, KDE framework must be fixed first, we will follow just after. My best regards Gilles Caulier
To sum it up, there are two bugs affecting the digikam configuration on Windows: 1. The digikamrc file is not stored in any digikam configuration parent folder in the generic configuration parent folder (this very bug), this bug lies either in Digikam or the said KDE framework. 2. The digikam configuration parent folder is stored in a disposable parent folder on Windows instead of the correct generic configuration parent folder (bug 382358), this bugs in fact lies in Qt itself. Unfortunately, fixing this very bug will still produce something wrong until bug 382358 is fixed), and we better get Qt 6 fixed instead. I just created the bug on Qt side: https://bugreports.qt.io/browse/QTBUG-129134 Once this bug is fixed on Qt side, using `AppConfigLocation` on Windows will fix both this very bug _and_ bug 382358. Actually using `AppConfigLocation` should be what to do on both Linux XDG, macOS and Windows, but unfortunately Qt wrongly implemented `AppConfigLocation` on Windows because Qt wrongly implemented `GenericConfigLocation` to begin with. I hope Qt will fix that bug soon, and sorry to have failed to report that Qt bug on Qt side before. Unfortunately this may not be an easy task for them because fixing that bug without implementing an automatic migration will make decade of released Qt applications losing track of their original configuration… I can't help but recommend to encourage Qt developers to fix this bug. KDE developers may want to already use `AppConfigLocation` starting with today to fix this very bug but this will require a migration path code on KDE platform too, since there would be two migrations to be done (one on KDE platform for this very bug: moving the configuration file to a subfolder, and one on Qt side: moving the configuration folder to the right place), one may wait for Qt to fix their bug first, or make sure both migrations will never break the other one whatever which one is done first. So yes, KDE platform storing the `digikamrc` file as `AppConfigLocation\digikamrc` should be the solution, but this will still be wrong because of Qt's own bug.
I think that the KDE developers are already aware of this. Because the new digikamstaterc config file (saves window positions) is already saved under .local/share/digikam or, under Windows, in the corresponding roaming directory. However, we can save our config files that we have control over, i.e. digikam_oauthrc and digikam_systemrc, in the correct directory. Maik