That patch fixes the build problem I got into today when trying to build 2.3 for windows. So ? from me and please commit the patch as it is already required when assuan and gpgrt config no longer emit ws2_32 in their pgk-config --libs line.

I just saw that there is related discussion and a patch for this in T4994 so I will close again here.

to give you any help I would need to know the exact error. I can only tell you that this is not a problem related to Gpg4win something else must be messy on your system. The Uninstaller of Gpg4win cleans up all registry keys that do not contain user config and all files should be removed unless some other process on the system interferes.

This change broke for me the compilation of GPGME which I fixed with: 52f930c1ed7eee6336a41598c90ef3605b7ed02b I found that fix there OK because GPGME explicitly uses ws2_32.

Phabricator allows it again to upload patches. It's D507

In Kleopatra/src/dialogs/subkeyswidget.cpp there is already a context menu for subkeys.

Still an issue, just noticed that with the 3.1.12 release announcement, it really looks ugly.

Or when there is no name the email will be taken:

Hi, yeah its complicated for Kleopatra to detect the defaults as they can be set both in Kleopatra config and GnuPG config. The GnuPG config overrides the Kleopatra config. Kleo has code to handle this but not when it adds the comboboxes to the GUI. So I've just removed the "default". We only had this for RSA and DSA / Elgamal, for ECC we did not indicate the default.

I can reproduce the issue. GpgOL creates a temporary file using the original filename and that fails because the pipe is one of the invalid filename characters on Windows / NTFS.

After digging through our complete parser code it turns out that we did everything correctly but Outlook adds the line break when we change the bodyformat from HTML to plain text. So this issue only existed since the fix for: T4639

It's not only for URL's. I've tested with any long line when sending "text/plain" GpgOL properly sends this but displays it wrongly.

Hi,
could you please change the edit policy back to all users so that I can change the status of this task?

I think this might be the issue with High DPI support problems. T4819 which is not yet released.

Argh, I had overlooked that you even mention a pull request.
So Apologies that I did not attribute the fix directly to you.

Thanks for the nice report. The fix was completely straightforward, I just didn't think about rich text when I implemented it.

MAPI Namespace has a pickFolder method which can be used here.