As shown in the above screenshots the fix was tested by me.

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:

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.

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.

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.

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.

I think that this would be more like something for a "Task" in Kleopatra and not for a job in GPGME. As a job usually is only one operation and having a single job do two operations is different from the rest of the API. So I would be against it. A signEncryptJob is IMO something that should be reserved for a time when GPGSM supports gpgsm -se

We had discussed this several times in the past as this is similar for files. Like you could do an opaque signing and encrypt for files, the same you can do it for text here. But as I remember it the end result was mostly that since the proper solution would be for GnuPG to support that T2435: gpgsm combined sign and encrypt it should be done in GnuPG proper. And we really did not have any real usecase of S/MIME file and text encryption since S/MIME was even more then OpenPGP about Mails for the Gpg4win users.

Since Kleopatra does not suppress the pinentry prompts think there is even one additional question at least for S/MIME. So it asks you once from Kleopatra and then you are asked by GnuPG.
AFAIR we had discussed this in the past and also came up with the Idea that the user should type in DELETE. That dialog should then come from GnuPG I think so that it is the same.

No. To solve that problem we have the revocation certificates autogenerated in the GnuPG home folder and which are kept of course when a user deletes their key.

Mh, no, on the other hand the style is useful in the "All certificates view" to make distinctions based on multiple parameters. "Like trusted S/MIME root certificate" and it is useful to see that right away instead of using the filters. So my vote would be to clean it up, but keep it in general.

Hard to decide as we have no data how much it is used. :-/ But I tend to agree here. We should not loose sight of the fact that Kleopatra should be more of a diagnostic tool and provide all the information a user might need to solve their issues with signing, verification, encryption and decryption. Kleopatra is not something a user uses so often that they play around with appearance or so like they maybe would in a MUA. Certificate management is just an unwelcome side effect required for crypto. But users do not want to do certificate management for its own sake.

In T7212#188683, @ebo wrote:

We might also consider going all out and allowing a configurable appearance on a per certificate level. Then this feature would see an increase in use for sure. But it should work without issues, in that case, as then people will notice them…

Uhm this is a task I have with High priority. I do not know what to do here or what it is really about. -> Invalid.

Yes, this is all something that is ugly. The VS-NfD colorization was done by justus winter back then since I fell sick and it was one of his first and only tasks in Kleopatra. So it is normal I think if that is implemented differently then other things. And in general the whole appearence configuration is I think rarely used. To me it always felt like a "We add it because we can." feature. But also with this mix of filters defined in a preinstalled libkleopatrarc and additionally hardcoded filters it is all strange.
Well colors and so on should be changeable for accessibility of course.

Wouldn't this usecase be better solved if we could highlight trusted-keys in the keylist better? I mean not trusted-keys as in "this key has full trust" but this key is one of 1-10 (In real life the most we saw was 5) which is configured as a TrustedKey

TrustedKey1
The value specifies a fixed trust root (trusted-key). If more than one trust root is required, the entries TrustedKey2, TrustedKey3, TrustedKey4, TrustedKey5 may also be used. Take care to specify the 40 hex-digit fingerprint of those trusted keys.

The problem here is that Kleopatra could do that of course, e.g. after importing a file. But this has to be done by the GnuPG system to handle all the automatic cases etc.
I leave this up for triage, since I am not sure if this is a bug, or a feature request. @ebo I believe you said to me that you tested this with keyboxd? As my answer would have been that keyboxd would be required for a proper solution to this.

I think we can close this as Wontfix since it is our opinion to wont fix this issue. If there should be more prevetion of accidents it would probably be better to have the user type in "DELETE" or "YES". Anything else then another click confirming a popup. Since this will just be clicked away through muscle memory. This came up again in T7211: Kleopatra: configuration option to prohibit deletion of certificate with secret key

In MMO Games this is usually handled that a player either has to type in "DELETE" or type in the Characters name to delete the character. At least in the last games I played.

KWin has a script called "Dim screen for Administrator Mode" which mimics the windows behavior.

I would give this low priority. There is no way to prohibit that except if the user has no deletion rights on the file system. There are already multiple dialogs asking the user to confirm the secret key deletion. A user could by the same logic "Free up some space" in their local home directory and delete %APPDATA%.

Yes this was just a performance thing and had no other UX reasons so we can change it.

Ok, well in the days were did not have that much development power on Kleopatra and GpgME refresh keys just took the lazy part and offered the gpg output in a window. I still think that can be useful (e.g. diagnostics) to have as an additional details button. Especially in case of errors. What very often happens here is that the online access gets blocked somehow maybe even only to some servers. I am not sure if the numbers are really a helpful information. Please keep in mind: What do we want to inform the user about? If the user just sees some numbers is this really helpful? I think the user might want to either see which certificates were updated and which werent or if there were any problems updating. Personally I would find the information "what" changed the most important but that seems to me like too much icing on the cake. Like

• Changed expiry: foo@bar.baz <0xbadbeef> boo@bar.baz <0xa....>
• New signatures:

....

• Changed subkeys:

....

we are doing this for the last releases. The list of files can also be found in the repo now in gpg4win.mk.in

Will this be backported? Since the pgpcardwidget otherwise contains strings which are neither in master nor in kf5 I would say so.

I and most users don't read what software says and just click where I think I reach my goal fastest. If there are only instructions to do something I am unable to continue.

No I don't think we should support that. I just meant that at first start we have to expect that the user does not have a secret key yet. And offer an easy way out of this by generating one.

Yes sounds good to me. Since we have the ability even in the full list view to filter for "only with secret" certificates. Regarding gpgme_set_sender. Only GpgOL uses this, we only really need it for TOFU I think. To leave that discussion / point out of this issue I created T7199: KMail / Kleopatra: Use gpgme_set_sender to add a hint which UserID was selected for a signature

Yeah this task is a bit bad as it does not really split this up into actionable tasks. But I found it obviously "ugly" (Since QWizards are ugly) and from a user experience standpoint outdated that I thought a general task would be enough to say that this must be changed and improved. The first start is the most important one and to be greeted by a wizard which I still am apparently where I don't really understand what the software wants from me is strange.

For me each time wine is upgraded I get for the first time an error when building something, but it is not slow anymore. Is this resolved?

No next work item here. So resolved.

As there does not seem to be a problem here anymore -> Resolved.

I don't think this ticket is up to date. Especially since we now have more components. Auto update or Microsoft Store integration would be much more important then a single click installer.

This is fixed

So Tobias fixed the technical reason why there was no import tab shown after the certify questions because I was too lazy (no I had no more time ;-) ) when I implemented this to carry the keylistcontroller around.

I've talked to ebo about this and yes she will create subtasks for at least GPGME log an qDebug logging the GnuPG Logs can already disabled in the config so we dont really need it. Currently it looks like this and I find it rather confusing:

The unexpected behavior of the MAPI store needs to be tested and handled. I had indeed forgotten about POP Mail in my concerns not to leak decrypted mails back to storage.

Resolved and customer confirmed this

No, if you then find out that you cant reach anyone in the protocol you should be able to get back.

In T6813#184976, @ebo wrote:

Works on Gpg4win 4.3.1, too.

But noticed an inconsistency for the key creation via GpgOL: Contrary to the behavior for key creation in Kleopatra in Gpg4win, you are asked for a password for the new key.

For VSD I somewhat agree since this is the difference between a VD Compliant signature. For the community edition though level 2 is usually enough and should also be indicated as trustworthy. So I am currently in two minds about this.

In T7064#184630, @TobiasFella wrote:

Can you clarify on what the show parameter is intended to do? I don't yet see how it would be useful, as the distinction between VSD and gpg4win is already made by whether the respective file is present or not