Version 3.2.2.2405000+git~ (Gpg4win-4.3.2-beta41):
works as described with pkcs#15 and netkey cards.
(The column width is then the same for those cards)

With the fixes a build from Gpg4win master (kf5) should now no longer switch the colors or the icons when in dark mode. This should only be done in high contrast mode. I am adding screenshots from the tests here so I also don't get confused between the different versions:

https://invent.kde.org/pim/kleopatra/-/merge_requests/255 fixes some low-hanging bugs to make the configuration behave more as expected

All given data files are concatenated; not sure whether this is a good feature but iirc pgp 2 did it the same way.

BTW, gpgme does not yet use --quick-set-ownertrust which can also be used to set the disabled flag. We should replace the interactor by the new command. See rG21f7ad563d for the new command.

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

Thanks for this prompt fix! but they're still not aligned. with this fix, the Synopsis is:

We could also phrase it more like a sentence, something like

ok, here the comments from our joined feedback session:

For the certificate list it might make sense to have column-specific tool tips, e.g. to give details on "not certified" in the "User IDs" column. For the fingerprint column (just to pick one example) a tool tip makes little sense.

I started working on this already since we needed to fix the current changes regarding dark mode detection. T7214: Kleopatra: Dark mode detection problems on Windows 10 2016
Darkmode detection in Qt6 works for us, but the icon theme switch does not happen.

The latest changes have been backported for VSD 3.3.

https://invent.kde.org/pim/kleopatra/-/merge_requests/176 removed the checkbox for encrypting to others

Comment edited. We still might want to have that discussion about what we should aim for but this ticket is not the correct place for it. Apologies.

Kleopatra of course respects the disabled status because GnuPG does so. But what is the usecase for further extending this?

I fully agree with ingo.

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.