Normal priority to get the _1_ removed when no folder with the same name already exists in that location.

Strangely enough this does not happen on linux. Maybe related to the KMime changes we have there?

For S/MIME archives the output for e.g. testfolder.tar.gz.p7m is now named "testfolder.tar.gz_1_/testfolder" with the "_1_" even added if there is no "archive.tar.gz"

Fixed in master.
Will backport into 2.4, after testing.

Current progress left being the qml version for Kalendar and right the QtWidget version for Kleopatra. This still require some work in the QtWidget viewer to display that the message is signed and encrypted

So some more data from 2.4.3. Once unpatched and once with your patch.

One complication comes from the fact that gpgmepp and qgpgme include the global config.h that is generated by configure. This needs to be replaced. I'll attach two files where I grepped for usage of the config.h's #defines (generated on Linux) in lang/cpp and lang/qt. The files probably contain false positives.

I was able to find the Craft blueprint with the CMake build system in my Win VM and pushed it to invent: https://invent.kde.org/packaging/craft-blueprints-kde/-/commit/5e9aae4d006f69657d3612c2fe398c9e5ae69ac0, feel free to use it for inspiration or base for future work, or ignore it completely :). It's probably far from a production-ready CMake script, some years ago I just really really *really* wanted to build KMail on Windows (don't ask why) so I did some unspeakable evils to make it happen. This is one of the better things that came out of it...

With the added MIME types Kleopatra now suggests archive (1).tar.gpg as new file name, at least on Linux. Needs to be checked on Windows.

Merged into master: https://invent.kde.org/pim/akonadi-calendar/-/merge_requests/59 and should be available in Release 23.08.

I had to fix it anyway in order to be able to provide screenshot for the latest blog post about encrypting invitations :)

See T6585 for the 1.21.0 release

Am I correct that the reason for the speed up is that it can use a second CPU's engine. If there is a real performance improvement here, we should add this for example using a --compatibility-flag. This way we can gather experience and eventually make it the default. The compatibility flags won't introduce an API incompatibility.

I found this important to do because the SHA-256 results from your test looked extremly slow.

For comparison here are my benchmark results on the same system. Once on Linux 64 bit and once on W32 and once with W64. All runs are native to exclude any virtualization issues.

Updated the patch:

I see little value in viewing emails in Okular. People often want to reply to emails so they need an email client anyway. Or shall Okular get a composer and save the composed email (of course with signing and encryption) to disk so that people can give their reply to their correspondents on a USB stick because that's more secure than using an email server? I suppose it makes sense for spies. ;-)

Thanks! I thought about that when I saw Werner's change in gpg, but would probably have forgotten to actually change it in Kleopatra.

Yes, this might make sense to have a library for the core parsing / reparsing part and then maybe some widgets in Libkleo that could be used to show the information. So that we could in theory create a small executable that just instantiates a libkleo widget to show a MIME mail and Kleopatra could use that then, too. But for clients like Kalendar which don't necessarily use QWidgets it is porbably better to have this split out.

Note: The gpgsm engine of GpgME supports the offline flag (which maps to --disable-dirmngr) only for keylist operations. gpgsm_import doesn't even have an engine_flags argument.

works, I did not encounter the issue following the description

works. So gpgtar obviously knows about the filenames now, too

as this task is for a technical restructuring task, which is obviously done and works, closing this ticket.