That said I think we should then strive to use only one "next" window.

Revocations are an exceptional task and rarely needed. In this case ("help, help , my key is compromised, what shall I do now?") an extra dialog to help the user is imho appropriate. This different for the key generation process, becuase this needs to be done by every user at least once and thus should be UI-wise as simple as possible.

"Today" was already removed together with other changes for T6621: Kleopatra: Remove "in n days/weeks/months/years" input from Change Validity Period dialog.

I just want to point out that we have explicitly decided to remove confronting the user with five different "What next" options in the certificate creation workflow. One reason is that the choice overwhelms the users because some think they need to do everything. Another reason is that many options were completely wrong for some of our customers. Such workflows are much better documented in company-specific SOPs (standard operation procedures).

Fixed. This improves the first impression when users use the first smart card with Kleopatra.

Fixed. Two examples:

Fixed.

Oops. I closed the task accidentally.

We decided the latter is to small an issue, we'll close this ticket without opening another for the reverse case.
Tested only in VS-Desktop-3.1.92.39-Beta yet

I don't see a problem here. Of course Kleopatra could run a gpgconf -K all when it really exits but I doubt that we need to do that in this special elevated case

Fixed (for GnuPG 2.4). I hope 2.2 prints the same status messages.

The General Error happens also when the PIN is blocked and no Pinentry opens.
As in this case, where the indicated "Generate New Keys" button was used on a blocked card.

This change also avoids the accessibility problem (from the report) that tool tips close automatically if one moves the mouse cursor out of the tool tip.

Note that the keys do not have origin information before they have been imported. My idea was to keep track of which job generated the results and somehow add this as origin information to the key list model.

Okay. 2342304000 in the colon output is 2044-03-23T00:00:00+00:00.

Yes, this ticket was made as a task to be completed for vsd33, so we left out the refinement you suggested on purpose.

As we are running as 32bit software on Windows, the "?" in the output below are a matter of course.

Since we can have multiple servers for S/MIME it could be nice in the search results to sow from which server the reply came. But I think that is out of scope or better a different issue since the current API does not provide that info.

What does gpg -k / gpg -k --with-colons say?

yes, the box comes up, the second "user-level"-Kleopatra exits again after clicking the "ok" Button.
After quitting the Kleopatra process with the admin rights again the privileged background processes remain, like I mentioned in https://dev.gnupg.org/T7050#184583.

Yes, the kleopatra.exe process ist shut down for me with that version, too.
But I wonder if the remaining gpg-agent and scdaemon processes which remain may cause issues later on. The are still running with elevated rights according to the process explorer after restarting as normal user. It does not cause any immediately obvious issues, though.

No more additional dirmngr.exe processes come up in VS-Desktop-3.1.92.39-Beta, too.

Following your suggestion I have created T7067: Kleopatra: Add origin information in search results for the last open point

Note to self: The error message that nothing was found on the keyserver will still come up if one is configured. That will be fixed with T6493.

The certificates from the same test smart card work in Version 3.2.2.231170 (Gpg4win-4.3.1), too, but there all certificates are shown, that is one more than in the VSD version. Seems gpg2.4 can handle certificates which 2.2 does not accept. But that is nothing to complain about.

ok, then I set this ticket to resolved, as it now works in version VS-Desktop-3.1.92.39-Beta as far as in Gpg4win.
That is only the "Refresh Keys" does not work yet. Which we now track in the above mentioned Tickets T7036 and T7037

Sure WKD is still checked if the conditions for an update via WKD are fulfilled.

It's not a different kind of data. In both cases it's the serial number of the smart card either in human readable form (often as printed on the smart card/USB token) or in "untranslated" raw form. It's a bit like short Git hash vs. full Git hash.

what about the case that the key has a mail address? Is WKD still checked?

works for latest VSD Beta, too (VS-Desktop-3.1.92.39-Beta)

looking at my private key directory, the data for the display serial number seems to not always be there FWIW.

While reviewing the changes I had some doubt about some of the columns.

In a current version I see this at least if I do not quit Kleopatra completely and restart to another screen setting. Further testing at the moment is not warranted, as there will be changes to the columns handling with the switch to Qt6. (T6924)

From your description it is not clear what you did exactly.

Works for me using the latest vsd beta (3.1.92.39)

I think last time we talked about some generic solution for this. And ended up trying to research if we could add this in the end after linking is done to avoid having to patch/add an RC file for every library like GnuPG. Kleopatra and GpgOL already has one as you can see in windows with right click / properties and then details. Maybe we need to change the values there.

I agree with the column save /restore but i disagree with adjust to contents since this can create a "jumpy" layout e.g. with long comments and the user might be annoyed if she changed thr layout and it is then automatically changed again

Done and backported for 3.2.

Sorry I just noticed that I mixed up the duplicate closing. I wanted to close 7050 as a duplicate of this and not the other way around. Since this description was more general and better.

Just to triage this