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.

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

Found a workaround for me. I thought that to only set gitrep if it is not set an ":=" would be required but as other variables in there were also assigned by a single equal sign, I tried to set it on the command line, too and this worked.

Sure! I agree. But my commit did not change that, it only changed that if it that preferable source directory is not at the expected place that it falls back to a remote connection. Since this is also not done in release builds etc. I don't see the harm. And it makes it easier to build GnuPG I think it is weird that users need to modify the script for a git build, this is also not documented. Or a manually reviewed source tree setup under ~/s . But the maintainer could have such a setup and so that setup is preferred! So nothing has been changed for the maintainer.