tested with VS-Desktop-3.2.93.391-Beta, looks ok.

Fixed and backported for VSD 3.3.

The texts were changed as discussed in the linked MR. I haven't changed the order of the buttons.

In the Qt 6 version the DeviceInfoWatcher can be enabled on Windows for A/B testing by adding the following config option to kleopatrarc:

[__Experimental__]
UseDeviceInfoWatcher=true

I have reverted the changes (also for VSD 3.3). I'll set this to open again and lower priority to low because the legacy file watching seems to work on Windows. We can revisit enabling the DeviceInfoWatcher on Windows when we have time to look into the root cause of T6688.

Hopefully fixed by disabling the DeviceInfoWatcher on Windows again.

I don't think we need a fallback. For the group configuration we can manually look in the old location. And for everything else it's okay to lose the configuration.

Problem is that this approach doesn't work for settings that are read/written by KF, e.g. the language settings if people change the application language. I also don't particular like the Krita approach of forking everything. n the other hand, patching Qt is also suboptimal and doesn't even work for builds we don't control.

Problem is that this approach doesn't work for settings that are read/written by KF, e.g. the language settings if people change the application language. I also don't particular like the Krita approach of forking everything. On the other hand, patching Qt is also suboptimal and doesn't even work for builds we don't control. Maybe KConfig needs a way to override the default config location retrieved from Qt.

I have a proof of concept for the second part, for reading config from ~/.gnupg/kleopatra/kleopatrarc (while still supporting the legacy ~/.config/kleopatrarc) at https://invent.kde.org/pim/kleopatra/-/merge_requests/199

The first part, getting the KMessageBox don't remind me checkbox to store the config at the same places as the rest of Kleopatra is handled by https://invent.kde.org/pim/kleopatra/-/merge_requests/193 .

Resolved and customer confirmed this

Please, we need a fix here for 3.3.

Go ahead and split it of, then. And setting a key to disabled in Kleopatra itself is not that urgent that it has to be in vsd33.

I think Kleopatra now respects the "disabled" state of OpenPGP certificates. I don't remember the outcome of our discussion about allowing to disable OpenPGP certificates from Kleopatra, but I think this should be split out of this ticket.

Tobias should have addressed all points (except using ISO format for dates which we won't change in Kleopatra).