Not sure about gpg4win 4.2.0 but we had a bug in 4.3.0 which has been resolved with T6985

Tested with a Gpg4win-Beta and VSD-3.2.94.474-Beta:

https://invent.kde.org/pim/kleopatra/-/merge_requests/337

I edited the task accordingly. Here I meant Notepad. But I would also add this as an idea / improvement for the clipboard if this should get improvements.

Ingo prefers to hide the origin by default, so please make this one change so that the UID tab columns looks like this by default:
Name, Email, Trust Level, [Origin], [Tags]

In T7362#195689, @alexk wrote:

Yes, automatic scanning of the clipboard is not good. I withdraw the idea.

I am not sure if it helps if I comment, I just saw that this is issue cropped up again, and although we might be seeing different problems since other reports like T6623: Kleopatra hangs "Loading certificate cache" on Windows 10 T4581: Kleopatra stuck in loading the certificate cache are about indefinite hangs. (Was a timeout added in a generic place recently?) I just hope that at one point the underlying cause for this is found and resolved instead of hiding the symptom each time we find a way to reproduce this a bit better. Seeing T7437 and T7438 in which I commented a bit more made me sad that this is still not treated as a GnuPG issue.

To explain why I have not changed this, even though we have observed these hangs for years. I have never been able to reproduce a hang or issue without Kleopatra and only GPGME and only through keylistings. I just looked and still had the scripts I used for testing to mimic the calling pattern of Kleopatra lying around since this code is also run each time the security approval dialog is shown in Outlook.

Closing since the cause for this was identified.

I agree here with Werner. Changing the fronted to workaround locking / timing issues in the backend like in T4505: SM, W32: GPGSM hangs up the GnuPG System T6323: Kleopatra: Import multiple certificate files one after the other might be necessary in the short term to make a release possible. But even if, like in T6323 the code which avoids the issue is better this should rather be the last resort or done after doing a fix in the backend or to avoid the issue with older versions. I just wanted to comment because I clearly remember that in T6323 I was very glad to finally have a way to reproduce a deadlock with a high probability and then very frustrated that the issue was left in the backend and only hidden in Kleo.

Or maybe not. I just did 0.11.0 (T7449) and will do more releases if there is demand for it or we have collected enough patches.

In T7437#195688, @werner wrote:

I don't really understand the problem. After all gpg-agent seems to be started using gpgconf --launch gpg-agent which should handle the locking properly.

I think then we could also include this idea: https://dev.gnupg.org/T5006#195230
And thereby show this information for notepad imports, too

If we're looking at changing this workflow, we could also consider how those dialogs (especially the "Certificate Import Result") dialog relate to the "Imported Certificates" tab - maybe we can find a way of showing both the relevant contents of the tab and the dialog in a unified view and then no longer need the dialog

All changes proposed here have been implemented. I do plan more changes, but will put them in separate tickets

Yes, automatic scanning of the clipboard is not good. I withdraw the idea.

I don't really understand the problem. After all gpg-agent seems to be started using gpgconf --launch gpg-agent which should handle the locking properly.

VS-Desktop-3.2.94.474-Beta:
This is, what it looks like after generating the first key in a fresh installation:

Maybe we could join the two dialogs, i.e. add the additional text and the Certify button to the import result window.

On the other hand might 2 pop up windows after an import be annoying…
Although the second window has a "do not show again" option.
Any suggestions?

just a nit in the test name

In T7262#195642, @ametzler1 wrote:

I read this as bumping the version-number e.g. from 1.24.5 to 2.0.0 without e.g. bumping the soname or changing the api_version as specified in the .pc file. (FWIW I think that is a great plan.)

The title says "notepad". The description says "clipboard". What do you want?

Additionally permanently watching the clipboard for changes can cause some password managers to detect an "attack". As it is discoverable which application accesses the clipboard on windows we had the case where a password manager would not work when Kleopatras clipboard watcher was running. T6642

We'll do this with QGpgME 3. And it's easy to add new functions by using the NVI pattern and, if needed, virtual functions in the attached private classes. I've been using this technique for quite some time now.

Ah, ok I understood it as "we will change the soname for other reasons e.g. so that both versions are co installable but we will not break ABI". And I would prefer the break for qgpgme at least because of the mentioned problem not because I don't care about ABI stability but because I do and this is a big problem which only exists, because I didn't do it with the last repo move. There is no technical reason anymore for the abstract base classes.

Werner wrote:

We will bump the gpgme core version to 2.0 to indicate this split despite that there will be non-ABI/API incompatibility.

If the major version for QGpgME is bumped, shouldn't we at least remove the virtual base classes. Eg: delete FooJob and rename QGpgMEFooJob to FooJob. I did regret not doing this when i moved them out of libkleo since this architecture no longer makes sense in the standalone libnrary and technically the virtual bases make it nearly impossible to maintain ABI stability when adding functions. The reason for those was only because libkleo had that idea of different backends namely gpgme and chiasmus. But a Library called QGpgME should never provide another backend then GPGME IMO.
So no behavioural change at all, just something to make future ABI compat easier.