Yes, Kleopatra quits again with the beta from yesterday:

Fixed in gpg4win-5.0.0-beta476

Fixed by applying a patch to our version of MinGW. This affected all Qt programs build with Qt 6.10.

Yes, this is obsolete with T7717: Location of qt-application config files. Closing as Wontfix because we use product-specific folders outside of GNUPGHOME.

In T7285#209655, @ebo wrote:

@svuorela Isn't this done already for KF6?

@svuorela Isn't this done already for KF6?

Is this ticket obsolete with T7717: Location of qt-application config files?

This should better be fixed in the v5 release

With the product-specific standard locations implemented for T7717: Location of qt-application config files it's now longer necessary to customize the application name of Okular. Closing as wontfix.

The new approach has been implemented and backported for VSD 3.4.

New new plan (after discussion on 2025-12-08):

While working on https://dev.gnupg.org/T7962 I realized that https://dev.gnupg.org/T7717#208938 is probably not the best solution for separating the config files of different distributions of Kleopatra, Okular, etc. Changing the application name has many side effects, e.g. it changes the name of the config files, but that's unnecessary because we put the apps' files already in different folders. There are also other side effects that make things complicated (and require many changes in okular). Taking a step back what we need is different folders for VSD, GPD, and Gpg4win (and KDE Okular). And, for Kleopatra, we need different unique service IDs, but let's ignore this for now. That can easily be solved separately. For the different folders it would be sufficient (and maybe even nicer for selective backups) to use something like %(LOCAL)APPDATA%/GnuPG VS-Desktop, etc., as location for all apps' files of VSD/GPD/Gpg4win. Then we wouldn't have to change/patch anything in Okular (or any other Qt apps).

Backported for VSD 3.4

This is now implemented for Gpg4win 5.

For our GnuPG Okular, we should not use the standard file names (okularrc, …) as this would conflict with a regular Okular installation.

Looks good to me on gpg4win-5.0.0-beta413 @ win11.

I believe this bug was fixed by T7829. Please confirm with new gpgwin-5.0.0-beta.

Looks good to me on gpg4win-5.0.0-beta395 @ win11 (gpg 2.5.13).

Fixed in master: rGae431b04370f: w32:common: Take care of possible race on startup under Windows.

I implemented that in the old 2.2 branch for easier testing.

Please let us not clutter the code with OS specific things. We could use a gnupg_remove_ext or gnupg_remove_maybe_wait with a wait parameter which maps to a plain gnupg_remove for Unix. The GPGRT_PROCESS_DETACHED, in the asshelp is also the only specific thing which can be move to a file global macro.

I think that modifying gnupg_remove is a bit risky because it's used in many places.
I'd rather introduce new function for Windows; gnupg_w32_delete_file for this particular purpose.
Factoring out wait_when_sharing_violation function from gnupg_rename_file.

The gnupg_remove should retry if it has a sharing violation. Similar to what we do in gnupg_rename_file. I just figured that we do a remove in the latter function too w/o handling a sharing violation.

Here is a possible fix:

I can't find any causes of slowness in keyboxd initialization. I think that there is a situation where it simply takes time on Windows.