Bug 402346 - The digikamrc file is not recorded into the digikam directory
Summary: The digikamrc file is not recorded into the digikam directory
Status: REOPENED
Alias: None
Product: digikam
Classification: Applications
Component: Setup-Misc (show other bugs)
Version: 7.0.0
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
: 413489 452454 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-12-19 13:33 UTC by Loukournan29
Modified: 2024-09-20 06:01 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Loukournan29 2018-12-19 13:33:02 UTC
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
Comment 1 Loukournan29 2018-12-19 13:35:34 UTC
Please provide the resource moving at the upgrade to fixed version.
Comment 2 Maik Qualmann 2018-12-19 17:50:33 UTC
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 ***
Comment 3 Thomas Debesse 2018-12-19 23:15:12 UTC
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).
Comment 4 Thomas Debesse 2018-12-19 23:20:02 UTC
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%
Comment 5 Maik Qualmann 2019-10-26 19:58:56 UTC
*** Bug 413489 has been marked as a duplicate of this bug. ***
Comment 6 caulier.gilles 2020-01-12 16:59:55 UTC
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
Comment 7 Loukournan29 2020-01-14 11:03:09 UTC
(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.
Comment 8 Loukournan29 2020-01-15 20:21:11 UTC
(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.
Comment 9 caulier.gilles 2020-01-16 08:23:28 UTC
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
Comment 10 chasa.imago 2020-07-30 09:12:39 UTC
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]
Comment 11 Maik Qualmann 2022-04-10 08:47:17 UTC
*** Bug 452454 has been marked as a duplicate of this bug. ***
Comment 12 caulier.gilles 2023-10-15 12:37:54 UTC
@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
Comment 13 Michael Miller 2024-09-19 21:40:11 UTC
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.
Comment 14 Thomas Debesse 2024-09-20 01:51:56 UTC
`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.
Comment 15 Thomas Debesse 2024-09-20 01:58:50 UTC
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.
Comment 16 Thomas Debesse 2024-09-20 02:03:21 UTC
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.
Comment 17 caulier.gilles 2024-09-20 02:30:52 UTC
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
Comment 18 Thomas Debesse 2024-09-20 03:14:25 UTC
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.
Comment 19 Maik Qualmann 2024-09-20 06:01:58 UTC
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