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.

All changes have been backported for VSD 3.4 (because they are closely entwined with changes for T7717).

gpgrt 1.57 will come with gpgrt_fconcat. This can be used to get the sysconfig in a portable way:

Hi All,
Have you got chance to look into this issue.

The new implementation can now be tested (once we have GPD/VSD 4 builds)

Reopen because I'm changing the implementation

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).

I also don't think, that a backport to 2.2 is neccessary.
As gnupg26 was tested in gpg4win5 beta413 as well, I also move this to done on the gnup26 workboard and mark this issue as resolved.

I believe the reason was simply that we wanted it short, "Upload successful." sounds better than"Publication successful." and I associate keyserver more with upload than publication. Furthermore "Certificate successfully published" has the disadvantage of being correct only for the upload of one certificates, not multiple. So you'd have to have case differentiation.

@werner For rCd5e3cbfd , my mingw (GCC version 14) complains about the function-return-type difference of the prototype with GetProcAddress.

If we need to backport the locking fixes to 2.2, these two will be the start of changes:

Still good for experiments.

That RFC is Experimental anyway

Still good for experiments.

Fixed and backported for VSD 3.4.

Ranking as discussed with @ebo