Screenshots of current state:

Mark for backport. In the past all columns were resized to fit their contents when a single column was made visible.

Mark for backport

@werner Would it be okay to call gettext_use_utf8 (3) in gpgme's do_subsystem_inits where we currently call gettext_use_utf8 (1)? See https://dev.gnupg.org/source/gpgme/browse/master/src/version.c$77

Actually, it seems to be spelled "smart card" in English (e.g. in Merriam Webster and Oxford English Dictionary). Two words. It's just us ignorant Germans who like to glue words together as if there's no tomorrow.

Yes, the function to load the user-configured language on application start is very well hidden in kxmlgui. :-)

In the past I have also seen quite often that the Qt Translations with standard actions like OK and Cancel were translated differently then KDE Strings. So there is also some difference with that on Windows.

KConfig uses the default locale instead of the system locale by default it seems:
https://invent.kde.org/frameworks/kconfig/-/blob/master/src/core/kconfig.cpp?ref_type=heads#L118
This should probably also use a copy of ki18n's getSystemLocale() instead. Or we set Qt's default locale to this value to get KConfig to use it.

Don't change the existing KDE behavior for loading the correct Qt translations which is the same as gettext's behavior. It took quite some time to get it right on Windows for KDE. The important bits for making the language configured by the user work are in
https://invent.kde.org/frameworks/kxmlgui/-/blob/master/src/kswitchlanguagedialog_p.cpp?ref_type=heads#L64
where the user-configured languages are prepended to LANGUAGE and in
https://invent.kde.org/frameworks/ki18n/-/blob/master/src/i18n/main.cpp?ref_type=heads#L65
where we make sure that we load the correct Qt translations also on non-Linux systems (where Qt doesn't respect LANGUAGE).

All tables should now show the keygrip without spacing.

This task only dealt with the lower pane. It added the warning icon and the tool tip "This certificate cannot be used for encryption." For the upper pane see T6722.

Yes, we can phase it out in master which is what Nico is talking about and which uses Qt 6/KF6. Nobody is going to remove KIconLoader from KF5.

Daniel wrote a migration tool which was merged in January (https://invent.kde.org/pim/akonadi/-/merge_requests/154), i.e. a few weeks after he wrote the documentation. He foresaw that the documentation "will go out-of-date quickly". ;-)

Unfortunately, sentence like UIs are a nightmare for translators. The only thing that works for all languages is self-contained text fragments.

The latest changes have been backported for VSD 3.3.

Let's not make the filtering more complex. It's already complex enough with the search field and the filter drop down. If we want more flexible filtering then this should be solved in a general way and not as Sonderlocke for "disabled". "disabled" is really a niche feature and, in my opinion, doesn't deserve a prominent UI element in the main UI.

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?

Closing.

I cannot reproduce this with Version 3.2.2.2405000+git20240712T143635~6033869e1. I open the Details window, go to Subkeys, right-click table header, select Keygrip, close Details window, open it again, go to Subkeys, Keygrip column is still shown. Even after restarting Kleopatra.

The easiest solution would be a setting for gnupg. Then Kleopatra would just error out. But, as Andre rightfully points out, people will work around this restriction. Users are incredibly creative.

Just to clarify: I didn't say that we should remove the coloring/font style of certificates. I just said that I vote for removing the UI for changing the colors and font style.

I vote for removing the UI for configuring the appearance of the certificate categories completely from Kleopatra. This would solve all usability problems in an instant. People who want to go crazy with colors can edit the rc file.

The high-contrast modes disable all colors, but for normal dark modes we might have a problem with some of the predefined colors.

It's now possible to build the Qt 5 bindings and the Qt 6 bindings in the same build. In fact, it's the new default (if the needed Qt libraries are found).

It's not tagged vsd33 and I didn't plan to backport this since it depends on other changes (T6787) that are master-only.

Similarly, the table for NetKey cards.

For first feedback on the new slot/certificate table.

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".

Just a small addendum to what Andre wrote: Obviously, no tab should be shown if nothing was imported (i.e. numConsidered is 0).