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.

This is how it looked before (VSD 3.2.2):

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.

Well, now it does not occur for me any more, either. Ok, I'm setting this to resolved, this was most likely a situation where Kleopatra could not write to the kleopatrastaterc (in %APPDATA%\kleopatra\) for some reason. This would then be a more general issue, anyhow, for which we need another ticket if we can reproduce this.

I got confused in the various tests and mixed up the Qt6 test on normal Windows 10 with the Qt5 test. In the Qt6 case there are still issues, but that might be explained by packaging still. But for this we have less urgency.

The only change i remember and can find regarding that, is, that for the initial keylisting we disabled the check using the context flag T6261: Kleopatra / QGPGME: Use --no-auto-check-trustdb for initial keylisting since we suspected that this had something to do with reports that the initial keylisting either locked up or was very slow. At the least the goal was that by no auto check trustdb on the initial keylisting it would make it behave more consistently from start to start. But I am pretty sure that you told at least me, that Kleopatra should not try to explicitly do trustdb checks and try to manage that since gnupg takes care of this internally.

That's the way it works today in some organizations:
If users can't delete their key they are requested to ask their GnuPG admin, they actually do so and the admin does help.

I'd be in favor of keeping the UI and just fixing the most significant bugs it has.