I and most users don't read what software says and just click where I think I reach my goal fastest. If there are only instructions to do something I am unable to continue.

No I don't think we should support that. I just meant that at first start we have to expect that the user does not have a secret key yet. And offer an easy way out of this by generating one.

Yes sounds good to me. Since we have the ability even in the full list view to filter for "only with secret" certificates. Regarding gpgme_set_sender. Only GpgOL uses this, we only really need it for TOFU I think. To leave that discussion / point out of this issue I created T7199: KMail / Kleopatra: Use gpgme_set_sender to add a hint which UserID was selected for a signature

If you want to use gpgpass without a secret key, the most I would offer, if at all, is the option to use a symmetric key instead.
Maybe like this:

Yeah this task is a bit bad as it does not really split this up into actionable tasks. But I found it obviously "ugly" (Since QWizards are ugly) and from a user experience standpoint outdated that I thought a general task would be enough to say that this must be changed and improved. The first start is the most important one and to be greeted by a wizard which I still am apparently where I don't really understand what the software wants from me is strange.

We hereby deliver with some delay our completed version of the integration of PQC algorithms into Libgcrypt from our project. The code features the following algorithms:

ok, I like your proposal. To recap:

The socklen_t use are now being fixed in newer POSIX Issue 8, 2024.
https://www.man7.org/linux/man-pages/man3/socklen_t.3type.html

My summary here:

• Use of winepath by libtool is correct way for semi-hosted environment to run tests built by cross-build.
• (cross-)Build itself is possible with no winepath (or winepath -> /bin/false), if you don't need make check with semi-hosted environment.
• I don't see that it's too slow, these days. My environment is bookworm Debian (having Wine 8.0 something).

This behavior of the encrypt-to-others input field is intended. It avoids "Multiple matching certificates or groups found" errors if there is one current (good) certificate and one (or more) old expired certificates for an email address. There's a button to open a dialog listing all certificates so that the user can find a certificate they are missing in the input list's completion list. I think this is an acceptable compromise between making all certificates discoverable (even expired or revoked ones) and offering not too many irrelevant certificates. When the user selects a bad certificate in the selection dialog we should probably show a note that this certificate cannot be used instead of showing "Error: No matching certificates or groups found".

In T7183#188348, @ebo wrote:

I'm not sure if we are talking about the Encrypt-to-self drop-down or the Encrypt for others input fields. On the other hand, I see little reason to treat both differently.

At the moment they are treated differently. In the dropdown for encrypt-to-self no expired certificates are listed. encrypt-to-others does not have a dropdown. You are not able to find an expired Certificate by typing the name. But you can open the certificate list to chose from, where expired certificates are shown and selectable.

I'm not sure if we are talking about the Encrypt-to-self drop-down or the Encrypt for others input fields. On the other hand, I see little reason to treat both differently.

I agree with Ingo and Werner here. In summary

For me each time wine is upgraded I get for the first time an error when building something, but it is not slow anymore. Is this resolved?

No next work item here. So resolved.

As there does not seem to be a problem here anymore -> Resolved.

I don't think this ticket is up to date. Especially since we now have more components. Auto update or Microsoft Store integration would be much more important then a single click installer.

This is fixed

Fixed in: rG1e6b96577f68: gpg: Fix agent_probe_any_secret_key.

fixed in https://invent.kde.org/pim/kleopatra/-/merge_requests/243; we were not calling the visibility logic when initially creating the view.

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

• Don't show the tab if the certificate list was empty before the import
• Show tab when any keys were considered, not only when any keys were imported

are there any news about the problem with the control file?