If a high-contrast mode is enabled then Gpg4win 4.4 (and VSD 3.4) will use the Fusion style which works much better with high contrast than the Windows XP/Vista style with animations that was used previously.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Oct 6 2025
(auto resolved due to the keyword "resolved" in the commit message)
The window was not reenabled on failure see 8d174d5
Reading the commit log message in rG6dc3846d7819: sm: Support creation of EdDSA certificates.
I created a file to keygen.
Key-Type: ECDSA Key-Length: 1024 Key-Grip: 0286DCA85E771F64AB9FD9C89717369524D55471 Key-Usage: sign,encrypt Hash-Algo: sha384 Serial: random Name-DN: CN=dummy test nistp384
Oct 4 2025
That is on purpose. With a signed mail you have at least a way to tell who sent the mail. An unsigned but encrypted mail can be send by anyone and you netter don't use HTML links there.
Oct 3 2025
I updated the branch.
Oct 2 2025
This happens only in the 64-bit builds, i.e. with Gpg4win 5.
We also discussed emails that can't be decrypted. They are due to implementation details just currently skipped. They will also be so in the future as an implementation detail.
(removed: wrong statement)
Note: I also activated Sign/Encrypt by default, if that matters
I implemented that in the old 2.2 branch for easier testing.
Please let us not clutter the code with OS specific things. We could use a gnupg_remove_ext or gnupg_remove_maybe_wait with a wait parameter which maps to a plain gnupg_remove for Unix. The GPGRT_PROCESS_DETACHED, in the asshelp is also the only specific thing which can be move to a file global macro.
see also https://dev.gnupg.org/T7609
I think that modifying gnupg_remove is a bit risky because it's used in many places.
I'd rather introduce new function for Windows; gnupg_w32_delete_file for this particular purpose.
Factoring out wait_when_sharing_violation function from gnupg_rename_file.
Oct 1 2025
(writing this much later, since got lost)
I had a look at Qt 5. All of Qt's Windows styles are broken with regards to button or menu item styling. They change the background color of the hovered and/or selected button, but they use the default foreground color of the common base style class for the text. I don't think that fixing the (obsolete) Windows styles is worth the effort. As workaround we should use the Fusion style if high-contrast is active.
As this was finished more than a year ago, this should be included (and testable) in vsd