I added the burger icon to Gpg4win-master.
So remaining here is to remove the right-click actions when a certification is selected.

A better solution might be to use categories to have that element "this message will be signed / this message will be encrypted" above the edit window. But what I find more important and so much more a high priority is that in cases we have a failure saving the draft info flags an error message should come up. This happened for a customer and in the logs I could see that MAPI returned an error. the button was not toggled in this case but the mail also was not marked for encryption. T7144 is the task for that so I'd suggest to start with that one.

In gpgoladdin:

Changing the icon is unusual and does not match a native look and feel in Outlook where toggle icons are there for a reason, to be toggled or not. This is also the way how Outlooks native encrypt & sign works and Microsoft will probably have thought about this a bit.

Ah, that was what daniel and me actually talked about. So I was a bit dissapointed when I only found the documentation. :)

Btw. Here is a nice backtrace, which I think is similar to the crash part of this Task:

I think the crash in the end is the same we have in T6688: Kleopatra GPGME: Reported assert on exit where quitting kleopatra with running jobs tries to cancel all open contexts and then crashes where the assert would be triggered in debug builds. In T6688 we just hid this issue again by not keeping the deviceinfowatcher running.

Phew. Got it. a new script: "gccwrap.sh.in"

Well, so the documentation is that there is no way to migrate and you have to delete everything and then set it up manually again? In that case it is still missing the deletion of the KMail settings etc.

That fixed it.

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.