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.