In T7588#207022, @timegrid wrote:

• calendar (weekend days: general/selected/hover on dark background)

Tested on gpg4win-5.0.0-beta395 @ win10/win11

Fixed in 1.56.

Tested a little late and on Windows 11 with VS-Desktop-3.3.90.16-Beta (a Beta for VSD 3.3.3):

In T7758#205218, @timegrid wrote:

Note: If i set an invalid path in "Software\\GnuPG:Install Directory"

• the gpgconf -X output does not change
• the self-test Config File 'libkleopatrarc' fails with Error in archive definition tar: 'pack-command-openpgp' empty or not found

In T7758#205217, @timegrid wrote:

This probably can only be tested with signed releases?

Note: If i set an invalid path in "Software\\GnuPG:Install Directory"

• the gpgconf -X output does not change
• the self-test Config File 'libkleopatrarc' fails with Error in archive definition tar: 'pack-command-openpgp' empty or not found

This probably can only be tested with signed releases?

Looks good to me on gpg4win-5.0.0-beta357 @ win10.

Kleopatra from VSD installations should now use gpgv from the GnuPG installed by VSD when verifying the signature of the VERSION file. GPD and Gpg4win installations both use gpgv from the GnuPG installed at the value of the registry key "Software\\GnuPG:Install Directory".

Fixed with new GPGRT_PROCESS_STDIO_NUL flag.

It's intentional that with Gpg4win migration from %LOCALAPPDATA% does not work because %LOCALAPPDATA% is used by VSD (and GPD) but not by any old Gpg4win.

As timegrid has not experienced the older versions himself, he misunderstood this. Ingo's description is correct.
(%LOCALAPPDATA% was the location of kleopatragroupsrc before VSD 3.3.0.)

If we will fix gpgconf using GPGRT_PROCESS_STDIO_NUL, we will need to fix gpg-connect-agent to see if it's NUL or not.

For KF5-based builds this is resolved because the improved heuristic for detecting light high-contrast themes (like "Desert") is used for VSD 3.3 and Gpg4win 4.4.

Ok, it was a missing update (although windows claimed to be up-to-date).
After installing 2025-06 [...] KB5060829 the Microsoft Print to PDF feature is available again and printing also works in Kleopatra/Okular.

It's also the same error in Okular, when a pdf is printed.

Same on gpg4win-4.4.1 @ win11 (here a bit more debugview context)

3	3.503991	8584	kleopatra.exe	org.kde.pim.kleopatra: Paperkey export finished:  0 status:  QProcess::NormalExit
4	3.691599	8584	kleopatra.exe	QPrintDialog: Cannot be used on non-native printers
5	3.691981	8584	kleopatra.exe	QPrintDialog: Cannot be used on non-native printers
6	3.692752	8584	kleopatra.exe	org.kde.pim.kleopatra: Printing aborted.

Works fine here.

I guess, that's ok then, moving this to done.

In T7594#202471, @timegrid wrote:

Shouldn't the enabled close button in win10 / disabled text / nr2 have green color? (it's the "search certs on server" dialog).

Shouldn't the enabled close button in win10 / disabled text / nr2 have green color? (it's the "search certs on server" dialog).

This also happens on Linux. And even with the Fusion style.

Thanks for the Windows 11 screen shots.

Thanks for the feedback. The issues are the same as on win10:

Regarding the "unsure" findings:

• invalid state in cert list tooltip (red on black)

1. Issues found

Most issues with icons in high contrast modes (of Windows 10) should have been fixed. Needs to be verified especially with the high contrast modes of Windows 11.

Setting to Testing.

Yes, for GPD and VSD there probably should be version numbers in swdb.lst if the update check should actually be active in those distributions. I think for VSD the update check is usually deactivated because a) it accesses the public internet which some customers don't want and b) the software is usually not installed by the users themselves so that the update check doesn't make much sense.

So, what shall we do with vanilla kleopatra, or GPD or VSD? It will be easy to record current versions number in swdb.lst

Tagging with Windows because the update check is a NOP except on Windows.

looks good to me on gpg4win-5.0.0-beta190@win10

on gpg4win-5.0.0-beta190@win10 (high contrast):

I found more issues with the success, warning, and error icons we show in various places.

looks good to me on gpg4win-5.0.0-beta167@win10

For reference the related MRs for upstream:
https://invent.kde.org/plasma/breeze/-/merge_requests/540 (pending)

This might also be related to rGa7ec3792c5 (cf. T2982)

Fixed. If high-contrast is active then tool tips now use the same colors as buttons (e.g. white text on black for Kontrast No. 1).

With the above patch for breeze the toolbar and the configuration dialog title now also look correct in high-contrast mode.

The wrong/inconsistent coloring of the icons has been fixed.

kleopatrarc, kleopatrastaterc, klanguageoverriderc, libkleopatrarc, and kxmlgui5/kleopatra/kleopatra.rc are now copied from the old location used by Gpg4win 4.4/VSD 3.3 (%APPDATA%/kleopatra) to the new location used by Gpg4win 5 (%GNUPGHOME%/kleopatra) if they do not yet exist at the new location. This is also logged.

The migration of the group config file works again.

Right when you use a different homedir you also need to pass --homedir to gpgconf or set GNUPGHOME before invoking gpgconf. If you call gpgconf via GPGME the --homedir option is passed; afaics we don't have a kill option gpgme.

Released with libassuan 3.0.2 (T7163)

This issue occurs when using GPGME with multiple contexts and setting the OpenPGP engines to different GnuPG home paths. As you mentioned, it is crucial to let gpgconf know the correct home path so that it can locate the socket file used by gpg-agent and properly clean up all instances.

gpgconf assumes that there is only one of the daemons. In fact it can only work with one and that is the one daemon which listens on the socket. all daemon's do a self-check by trying to connect to themself and terminate if they realize that they are not anymore the owner of the socket. As long as a daemon is started by a gnupg component a file system lock is taken to avoid duplicate launching. However it a daemon is stared by other means this could lead to a race.

Maybe the title should be "Password - Kleopatra" (or similar) if the operation was triggered by Kleopatra.

Since codesigning for all dlls was added this is fully resolved.

Here is a patch to support "w32_error" for assuan_sock_get_flag function.

I believe this was fixed by T7386. Or it is now no hard lock up by T7402.
So, let me close this ticket.
If any new symptom, please add information into T7396.

I can say it's fixed in 2.4.7.