I think it's something special in Kleopatra in combination with your system. Kleopatra is deployed on loads of computers in Germany and you are the first one to report this problem. I understand that you do software development. Did you maybe set some localization settings or environment variables to test/debug things you develop? Can you try some other KDE application, e.g. Kate? You can get it from the Microsoft Store or alternatively at https://binary-factory.kde.org/job/Kate_Release_win64/.

The system language is German, the entire system is a German PC, German keyboard layout etc. Other languages used are English and Spanish.
The system is heavily used with different applications including SW development tools, etc.
Never noticed issues like this, so I am pretty sure it's something special in Kleopatra...

To me this looks more like a ki18n/Qt issue than a font issue. In particular, the key size drop down doesn't use a monospace font. The code uses the default locale to localize the number representation. What's the system language of your Windows?

Thank you for the fast response!

For S/MIME archives we still use the old code. gpgtar doesn't even support gpgsm.

Lets make sure that we look into this for 3.3

and with a renamed file:

This was already present in 3.1.26, where the error message was missing the output from gpgtar. So there was an improvement

can be tested with beta312

Damn this actually happens with every file with a space. Why didn't our Gpg4win users,.. report this. 😐 I checked T6056 was part of the last Gpg4win release...

Our current PKCS#15 widget is optimized for RSCS cards.

@ebo if tasks have a parent please directly assign them the same priority.

This looks very similar to https://bugreports.qt.io/browse/QTBUG-85744 for me nearly all emojis work except the frowning face please do not investigate the font / emoji issue further.

The numbers in this dialog come from system font setting for monospace fonts and that might be broken for you. But you should then have problems in other applications, too. There is nothing special here and it works for all our other users.

I am closing this as resolved for now. I would need a completely new client or mess with the registry keys in which outlook stores the performance data to test this. But I would bet it still lists us as responsible for the slow start of outlook. But the time it will then show should now be 0ms since we absolutely do nothing anymore in our DLLMain.

I don't really know how to test this though since it tracks this over time and history. Let us see if my change fixes this, It may be that outlook does not measure the DLLMain (which I am pretty sure it does) but the actual COM initialization, in which case my change did nothing. But I don't see any way in which my change could make things worse.

I think outlook shows any native addin there. As you can see by the empty bar we don't really do anything in there to slow it down. But let me check if I can move the extremely little code we have in there somewhere else.

Oh, the user is actually asked with this? I wonder if that is something that is new now, I think so. I mean its been quite a long time that we added support for embedded filenames but 3.1.26 was also long ago.

Looks like a missing unescaping somewhere in gpgme.

This is related to T6373. If T6373 is fixed, then we should get KIO's standard file conflict resolution dialog automatically. On Linux, you should already get the dialog which allows renaming the output file.

On Linux, gpgme already passes the locale (set with gpgme_set_locale) to gpg which should pass it with every session to gpg-agent. No idea if this also happens on Windows because there are some ifdef's. The gpgme documentation mentions that the locale should be set immediately after gpgme has been initialized and that gpgme doesn't do it itself because it wouldn't be thread safe.