The issue is resolved in gpg4win-5.0.0-beta479 @ win11:

• no error for opening .eml files
• no error for starting kleopatra while running (also not started twice anymore)

No it is not related to T4030 because that has not yet been implemented. I am just upload a beta479 which should fix problem as wel as other similar problems.

this also happens, when kleopatra is started while already running

maybe related: T4030: GpgEX: Use process calls instead of UIServer protocol

Indeed. We would need to add different entries to the context menu for each installation. Given that GpgEX needs to be replaced anyway and we will drop the need for a UI server socket (which is anyway only a trigger and no full communication).

Thanks for your work. I applied it to Gpgex.

Will do. Thank you very much.

Edit: The text below was wrong. The error given below only occurs when the combined path+filenmae is to long on windows.
An emoticon in a file below the folder to be encrypted does not hinder encryption via GpgEX.

Not sure yes If I rather fix this or do: T6331

Note to self after spending some time searching again for the documentation I saw previously about this: https://learn.microsoft.com/en-us/windows/win32/shell/context-menu-handlers#suppressing-verbs-and-controlling-visibility

Fixed in gpgex 1.0.8

Patch has been applied to Kleopatra. See T5619: Kleopatra does not create the UI-Server socket in the socketdir.

Okay.

Alternative patch for Kleopatra:

diff --git a/src/uiserver/uiserver.cpp b/src/uiserver/uiserver.cpp
index d9746f0b..ab4d2ca7 100644
--- a/src/uiserver/uiserver.cpp
+++ b/src/uiserver/uiserver.cpp
@@ -23,6 +23,8 @@
 #include "kleopatra_debug.h"
 #include <KLocalizedString>

Not from understanding. libkleo adds high-level functionality that's useful for KDE applications, but out-of-scope for gpgme and its C++/Qt wrappers gpgme++ and qgpgme. I would use GpgME::dirInfo() directly in Kleopatra. It would make sense to add an overload of GpgME::dirInfo() that takes an enum, so that one does not have to use the low-level string names in Kleopatra. The downside is that a string-based interface can be extended easily. OTOH, deprecating values of a string-based interface is hard and after removing it the compiler won't complain.

We want to deprecate the whole UI-Server thing and thus I considered it better to provide the generic socket dir instead of adding support in libkleo for the uiserver socket. For the time being, doing this in Kleopatra sounds better to me. From my understanding. libkleo shall be an interface to gpgme++, right?

gpgme_get_dirinfo does already have support for "uiserver-socket" since about 7 years. I don't think a separate "socketdir" which requires a brand new gpgme makes much sense.

For Kleopatra this patch

It will be useful to have support in libkleo: