I think the accessibility is okay now. It could be further improved with useful shortcuts for the different buttons, but the DN attribute order configuration is a rather unimportant UI of Kleopatra.

The command needs to be ported away from running gpg --export-secret-key via QProcess to using QGpgME::ExportJob. I'll give this a low priority.

But then again: The three other apostrophes that occur in the text are represented by single quote characters. Maybe sticking to ASCII characters is the better fix after all.

Typographically the apostrophe character ’ is a different character than the single quote character '. So, the correct fix would be to fix the probably wrong encoded apostrophe instead of replacing it by a single quote character.

Kleopatra now silently ends the "backup secret key" operation if the password dialog was canceled.

It turns out that gpg does report an error via status-fd, but it doesn't report via status-fd that the operation was canceled (Update: The error code 83886179 in the status message corresponds to GPG_ERR_CANCELED, i.e. gpg reports that the user canceled the operation.)

$ gpg --status-fd 1 --export-secret-keys --armor -- 3A8536D46F57779C49F0CF542C0444CB59852D29
[GNUPG:] KEY_CONSIDERED 3A8536D46F57779C49F0CF542C0444CB59852D29 0
[GNUPG:] PINENTRY_LAUNCHED 6899 qt 1.2.1-beta1 /dev/pts/47 xterm-256color :0 20600/1000/5 1000/100 0
gpg: key 79BF2044FA53B3A492B361882353B5828F9B391C: error receiving key from agent: Operation cancelled - skipped
[GNUPG:] ERROR export_keys.secret 83886179
[GNUPG:] PINENTRY_LAUNCHED 6907 qt 1.2.1-beta1 /dev/pts/47 xterm-256color :0 20600/1000/5 1000/100 0
-----BEGIN PGP PRIVATE KEY BLOCK-----

The second pinentry window comes up to ask for the passphrase that protects your subkey. Usually, gpg will try to use the passphrase entered for the primary key also for the subkey, but since you canceled the first pinentry there's no passphrase to re-use.

I have improved the cursor positioning:

• Keep the cursor position when a key/group is updated in the background.
• Move the cursor to the start when the user finishes editing (with Return), selects a key/group via the selection dialog, or moves focus to another UI element.
• Otherwise, we keep the default behavior.

Fixed.

This regression was introduced by rLIBKLEOf9cb0d3f03c6: Port filterRegExp to filterRegularExpression.

I'm not sure whether this can be solved satisfactory because we use different UI elements. For "Encrypt for me" we use a drop-down box because usually a user won't have that many keys (often only one), so that a drop-down box is more convenient than an input field with auto-completion. For "Encrypt for others" we use an input field with auto-completion because there can be 100s keys of others which makes using a drop-down box unfeasible.

In T6067#160368, @vitusb wrote:

Due to https://dev.gnupg.org/T5725#153224 ("The fingerprints are needed by Kleopatra as unique identifier for keys."), is this still implemented in that way ?

A screenshot would be nice.

It's already possible to define a short and a long hint for the constraints via the file doc/help.txt and its translations. This is a standard technique used by GnuPG for customization of several UI texts. Since the passphrase constraints can be very complex we don't try to come up with a suitable default hint.

Ready for testing.

Ready for testing.

You may be interested in https://dev.gnupg.org/T6070#160227

Ready for testing. See https://dev.gnupg.org/T6073#160145.

The standard Breeze icons (used by Kleopatra) are very dark because they are supposed to be used with a light color scheme. This can be "fixed" by the user by switching from the Breeze icon set to the Breeze Dark icon set.

If the high-contrast mode is active (on Windows), then we disable the usage of custom colors in Kleopatra. This avoids problems with too low contrast due to the custom colors.

Note to self: On Windows, we need to check whether the high-contrast mode is enabled. If yes, then we must not use any custom colors. KColorScheme doesn't help here.

The user id table is not accessible at all (neither the whole rows nor the individual cells).

We have KWatchGnuPG for watching the log files.

Due to vacation the review may take some time.

I suggest to submit a patch with the changes you'd like to see. Please read
https://dev.gnupg.org/source/gnupg/browse/master/doc/HACKING
for information how to contribute to gnupg.

It will hopefully be fixed in 2.2.37.

I'm not sure whether the manual page should be blown up to a full technical specification.

It looks like having it set will stop fallback from working entirely? Would you say that this cannot be fixed if WAYLAND_DISPLAY is set like I do above?