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.

I can confirm this

Works nicely for me in beta300

Looks good now

The Keyresolver did not allow me to encrypt to an S/MIME cert where the root CA was not in my trustlist.txt that was part of this feature to allow users to encrypt "non vs-nfd compliant" to such untrusted keys, like they would be able to also encrypt to untrusted openpgp keys.

New MR: https://invent.kde.org/pim/libkleo/-/merge_requests/61

MR for this: https://invent.kde.org/pim/libkleo/-/merge_requests/60/

I am temped to put the VSD-3.2 flag on it and raise prio to high because of strategic reasons... So if someone has a cheap fix for this. Please go for it.

Similarly if you decrypt with a PKI BW card and the mimeviewer there are also no longer problems which again might be related that the internal states where somewhat disturbed by the loop in Kleopatra.

I retested this with the current beta and It works without problems. I somehow suspect that the permanent access loop from Kleopatra caused other Smartcard operations to be canceled. Since the test setup is not really good to reproduce to for Ebo I resolved this myself.

Works on windows, too. VS-Desktop-3.1.90.295-Beta

works, VS-Desktop-3.1.90.295-Beta

works, VS-Desktop-3.1.90.295-Beta

I have added a workaround and tested it on Windows. Works now for me, including T6566.

@ikloecker I suggest giving up on this, I know that it is frustrating but it does not make much sense, it is probably related to some compiler settings / Qt cross compile issue and might be a bug in qt. Just do an old style connect and leave a comment that we will revisit this with Qt6. When VSD 3.2 is our last major release based on Qt5 we should not spend too much time investigating this which might be completely different (or not) with Qt6.

And it's the signals that are not found. I don't see any indication that this has anything to do with the slots/lambdas.

Well, the failed new style connects are logged for me with "QObject::connect: signal not found in QGpgME::QGpgMEQuickJob". I haven't dug into how the check works for those connects. It turns out that none of the three connects to the signals of QuickJob work (two of those connects are done in ProgressDialog). Even the connect to the argument-less done() signal. So this has nothing to do with default arguments. This is very disturbing because this means that any other connect might also be broken.

Ah no I see the difference here. Instead of connecting to a lambda with no args 96da231f97eff9485f62ab925d81252f5f97fc31 connected to the functions which were used in the old signal / slot syntax. I think the fix might be to explicitly list the args of the quickjob result or to use afunction to handle the keygenresult.

works, VS-Desktop-3.1.90.287-Beta

It does not log failed connections but new style connections are never logged when they fail. Since they can't fail ;-)

Let me put this on the 3.2 workboard since we already have the "reports error when canceled" on that workboard and T6566 too depens on this, in fact I am currently working on this even though it was not on the workbaord.

Seems T6813 blocks me from testing this. The generate window does not close and even if I abort the window, the generated key is not loaded. It is not selectable even if I remove the filter.

Does Qt log failed connections?