When I created the GnuPG VS-Desktop MSI Package I messed up and forgot about a file that Gpg4win writes where to place the config files.

So GnuPG VS-Desktop from the beginning placed its files into localappdata / seemingly random locations (https://doc.qt.io/qt-5/qstandardpaths.html) because we also do not properly set the organization in the QApplication. So this is not a regression. The files are in the same places as they always were in GnuPG VS-Desktop / Gpg4win respectively.

While by contrast Gpg4win neatly places its files into %APPDATA%\kleopatra thanks to a patch to Qt and a qt.conf: https://dev.gnupg.org/source/gpg4win/browse/master/src/inst-qtbase.nsi$44

Now the problem is, when I realized what was going on we already had widely deployed GnuPG VS-Desktop, and we cannot simply change that because then users will loose all their settings if we do not write a proper migrator that moves the config files around.

So I think the priority is mistaken because Gpg4win tests were in the mix. E.g. if you create a Group with Gpg4win it will not show up in GnuPG VS-Desktop. But If you create a Group with GnuPG VS-Desktop 3.1.26 it will show up in GnuPG VS-Desktop 3.2.0. If that is not the case then the priority here is indeed high.

We discussed this problem in Erkrath once and we think the only proper solution is for Kleopatra to place all its config files into gpgconf --homedir but this would mean to a) Patch Qt some more maybe even have Qt depend on GPGME (so that the gpgconf call is at least cached and does not slow down the startup more) and b) write a migrator for the existing config files.

This will definitely not be changed for 3.2 it will be a very invasive patch with a big regression risk and which does not make real sense to do before we switch to Qt6 since it involves patching Qt.

Also this the behavior we have in GnuPG VSD since the very first release. And more importantly is that all these additional config files are not settable through the Windows Registry.

So should we at the moment only change our backup/migration recommendations? Add %LOCALAPPDATA%/kleopatra and %LOCALAPPDATA%/*rc to the backup?

To be honest, the only backup worthy settings file of kleopatra is the kleopatragroupsrc right now. Most other settings are pretty much only for convenience I would not even bother to back them up. When something important is configured by the administration that should go through the registry. As we recently noticed, through talking to people at froscon and with the BSI the most common case was that our kleopatra settings were actually never updated or only saved by accident.

ok, then I'll add the tag for the VSD release after the upcoming one. It is of course relevant for Gpg4win also, but we do not have a dedicated workboard for that (at least not yet)

Well in Gpg4win it actually works better :) At least there the configuration files are all in one place (or mostly, or should be). Anyway a difficult issue which I am only planning to touch when we do the migration to Qt6 since this is heavily Qt releated. But the current plan (which might change) is to do that for the GnuPG VSD summer release which will be the next feature release after 3.2.