Note for devs: In most places we can probably use Key::isBad() which excludes all kinds of keys that are not valid for use (revoked, expired, disabled, ...).

gpgme has a disabled flag (only set on the primary key) and taken from the --wwth-colon listing where it is the 'D' in the usage.

GnuPG 2.4.6 will have a new command --quick-set-ownertrust which can be sued to enable/disable a key. We should support this in gpgme and make the interface general enough to also set the ownertrust. The latter is IMHO not needed in Kleopatra, though.

Of course, it should be possible to toggle "disabled" in Kleopatra.
A (context) menu entry "disable certificate" (or "enable certificate") should be sufficient.

I think Kleopatra now respects the "disabled" state of OpenPGP certificates. I don't remember the outcome of our discussion about allowing to disable OpenPGP certificates from Kleopatra, but I think this should be split out of this ticket.

Go ahead and split it of, then. And setting a key to disabled in Kleopatra itself is not that urgent that it has to be in vsd33.

with Version 3.2.2.2405000+git~ (Gpg4win-4.3.2-beta41):

What I see is: If the status of a certificate is "certified" or "not certified" before disabling it, then Kleo shows "disabled" in the User-ID column. If it was "revoked" or "expired", those are not changed. The same is true for the "Status" info in the details.
Is this distinction on purpose? What is the reason?

And I do not see any possibility to hide those disabled certificates. In my opinion respecting the state includes to not show such a certificate.

In T7089#188733, @ebo wrote:

What I see is: If the status of a certificate is "certified" or "not certified" before disabling it, then Kleo shows "disabled" in the User-ID column. If it was "revoked" or "expired", those are not changed. The same is true for the "Status" info in the details.
Is this distinction on purpose? What is the reason?

The order of states is "expired", "revoked", "disabled", "invalid", "certified", "not certified". Since we show only one state we need to define an order. I guess it would make sense to give "disabled" the highest priority. (I also think that "revoked" should have higher priority than "expired".)

And I do not see any possibility to hide those disabled certificates. In my opinion respecting the state includes to not show such a certificate.

Alex made different suggestions (which were not implemented yet). I think I'd prefer a configuration option to show disabled certificates (which defaults to hiding them). The suggestion to add a special filter showing just the disabled keys and to hide disabled keys for all other filters conflicts with the "All" filter. "All" should always be the superset of all filters.

The order of states is "expired", "revoked", "disabled", "invalid", "certified", "not certified". Since we show only one state we need to define an order. I guess it would make sense to give "disabled" the highest priority. (I also think that "revoked" should have higher priority than "expired".)

Ok, I agree on all points. Make it so ;-)

Alex made different suggestions (which were not implemented yet).

I believe that the ticket should have been made a parent ticket with the implementation tasks as child tickets. Like it is it is difficult to test and set a status to the ticket. As all the commits for the first task are on this ticket, I would make a new parent ticket with the original description and then change the description here according to the actually implemented part.

The discussion regarding the filters will go in another child ticket.

The latest changes have been backported for VSD 3.3.