In T2671#158357, @werner wrote:

It seems that editing a pre-created revocation certificate on Windows with Notepad doesn't let Kleopatra detect this correctly as OpenPGP file and thus refuses to import. Works on the command line but needs more testing.

I don't see why this would be a Kleopatra issue. How is Kleopatra supposed to know that "mytestfile.txt (002)" isn't the original filename, but just the result of another program that's too stupid to properly resolve filename conflicts?

Another idea would be a gpgconf daemon that answers all queries from its in-memory cache. Obviously, this wouldn't help with the very first start unless the daemon is started automatically on login which should probably be default behavior at least on Windows anyway. OTOH, gpgme does already cache the config so this would only have an effect when starting Kleopatra.

If the keys on the smart card are already known to Kleopatra/GnuPG (which should be the case if the smart card was inserted when Kleopatra was started), then on import of the corresponding public key Kleopatra now asks whether the certificate is the user's certificate (instead of asking whether they want to certify it).

Thanks for reporting. We usually test by moving the <keygrip>.key files around ;-)

For this I think a better solution might be if we would remove keys that are already in a group from the list of "available" keys.
By this I mean that if you edit a group and move keys down then they should be removed from the upper list of available keys so that it is easily visible which keys in your keyring are not part of a specific group.

done

works

very nice

This is now ready for testing. The import result dialog and the import error dialog now have an additional "Show Audit Log" button.

works