This works now.

Well for 3.3 we will have full support for high contrast with the correct icons on all platforms, additionally we detect and support dark mode on all Windows 10 Versions > 1709 So this can be resolved. (Both for Qt5 and 6). What I have not yet checked if Qt6::systemInfo::colorScheme reports the correct one under windows 11 desert theme, but as you mention that is also part of a different issue where when then also should clean up the kleo systeminfo etc. if this is reliably supplied as information by qt.

Setting this to testing. Could be tested as described in https://dev.gnupg.org/T7188#188093 by verifying that the logged debug messages also use correct encoding.

Okay. Done in gpgme for gpgrt >= 1.51 (T7188).

Sounds like a good idea.

@werner Would it be okay to call gettext_use_utf8 (3) in gpgme's do_subsystem_inits where we currently call gettext_use_utf8 (1)? See https://dev.gnupg.org/source/gpgme/browse/master/src/version.c$77

Alright: Call gettext_use_utf8 (3) to set the current thread to utf8 and init all new threads to utf8 as well. This function with that value (actually bit 1 is relevant) can be used several times but it will never switch back the initialization to utf8. However, switching back and force to utf8 per threads is still possible.

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

This should be tested as part of testing T5960 by checking that the German error description "Falscher Rückstellcode" is shown after entering a wrong reset code (PUK) for an OpenPGP smart card (https://dev.gnupg.org/T5960#188013).

Using/setting a value of 2 would work for Kleopatra.

That is probably right for gpgme as used by kleopatra. However in gnupg we need to switch utf8 on and off.

This also works for VSD 3.3 (because the required changes/patches are in gpg4win).

For the white high-contrast mode we use the normal (black) Breeze icons now. I think for Qt 5 that's all we can do with reasonable effort. For Qt 6/KF6 we have to revisit this anyway because a lot has changed (see T6932).

In T7175#187690, @jukivili wrote:

Hm, CFI directives should not be used on WIN32 target. This patch should solve the issue for now:

0001-src-hwf-x86-disable-inline-assembly-CFI-directivies-.patch984 BDownload

Using clang for Windows is not tested or suggested. Thus low priority.

Done in 3.0.0.

In future, when spawn function API is used by libassuan (and stable), we can support gpgme with no gpgme-w32-spawn.exe.
(And it will be simpler, just using native functions in libassuan, instead of replacing ones by assuan_system_hooks.)

The official GPG binary from "c:\Program Files (x86)\GnuPG\bin\gpg.exe" does not exhibit this problem. I will report it to the msys2 folks.

Yes, it is the msys2 build of gpg, installed using the standard msys2 methods. The pwd in my example was from msys2 zsh.
I reproduced the error running under msys2 zsh and in Powershell.
If I understand your response correctly, you are saying this will not be fixed in gnupg itself? I can report it to the cygwin/msys2 folks of course, if you think that is best. But I still suspect the root cause is in gnupg, probably in homedir.c or the code that makes an absolute path from a relative one.
I will retest with the official gpg4win and let you know the results.

pwd is not a standard Windows command. It is availabe in powershell but there I get

The reset was due to running gpg-connect-agent reset /bye. I am currently testing something elese will get back as soon as I can turn back to 2.4

There are two locks here; (1) rw_lock for card_top (list of cards) access and (2) individual card lock.
It looks for me that:

• don't know how/what the thread 7208.2 does
• the thread 7208.3: KEYINFO, then PKSIGN (gets read lock for card_top, then, individual card lock)
• the thread 7208.4: SERIALNO --all (and wait for write lock for card_top)

In case if someone finds it through a search:

Removing gpgrt because we meanwhile have full utf-8 support there.

That is an old bug report with a couple of fixes introduced over the years. As of now we sometimes see hangs on Windows on our test VMs. The common cause here seems to be USB card reader issues. Let's close this bug and wait for another bug report with current software versions.

No regression, assuming things work.

All icons that are available in normal/light mode should now also be available in dark mode.

And another note: In KF6 icon inverting happens automatically in ksvg or so, so that we don't need to ship breeze-dark anymore. And there will be a BreezeIcons library including the icons that can be used instead of the RCC file. This means we just need a quick fix for VSD and not a general solution for upstream.

One more data point: breeze-icons installs a copy of all breeze icons that do not exist in breeze-dark in the breeze-dark icons folder. So, with icon files on disk breeze-dark has all icons that breeze has even without using breeze as fallback icon theme. Looks like an oversight that the breeze-dark RCC generated by breeze-icons doesn't include missing breeze icons.

KIconTheme sets the fallback theme name to breeze, but those icons cannot be found because we only load the icon theme RCC for breeze-dark. I think we need to load both RCC files in dark mode. No, that doesn't work.

Possible reason: There's a kleopatra.svg in breeze-icons/icons, but there's none in breeze-icons/icons-dark.

I'd prefer to not use the spawn helper at all. All currrent Windows versions allow to decide which handles are to be inherited and thus there is no more need for the helper.

Thanks. I'll apply your patch.

Do you have any hint how I can test this? I installed Chinese-Simplified (zh_CN) but I fear switching the display Language. Maybe I should just use _wasctime and convert to utf8

Thanks for the report and the helpful suggestion. I was anyway about to change the time format but your suggestion is better.

Tested in VS-Desktop-3.2.0.0-beta214 by encrypting a large file with Kleopatra. The progress bar shows percentage finished, progress looks all right

Was already with gpgme 1.21.0. Note that I used the done column but in future a milestone would be more useful than that catch all "done".

But shouldn't we then rather rename the shortcut of Kleopatra to: GnuPG VS-Desktop - Kleopatra ? That would make it discoverable under both names.

Our sales team gets the support calls and they have to explain that really often.

werner I strongly disagree here. There is no need for this for our software on Windows and that is definitely not the Windows way, esp. with our current feature set. Do you really think a user wants to start "GnuPG VS-Desktop" to then have a selection between Okular, Outlook, and Kleopatra? That is not how this works at all. Definitely not High priority for us if you think Kleopatra is too hard to discover then we could add another start menu entry for Kleopatra called "GnuPG VS-Desktop" but a starter that only offers to switch between Okular and Kleopatra currently does _not_ have high priority, For windows this is solved with the windows registry, If you want to make Okular - GnuPG Edition your default PDF reader you can, similarly for Kleopatra and please also keep in mind that a user wants to "Encrypt" or "Decrypt" a file. And does not necessarily care about Kleopatra.

FWIW, we also need this for Windows. ppl often ask what to do after they installed VSD because they can't find a program. Thus a menu ala Kontact is the way to go. It would be linked directly from a GnUPG Desktop entry from Windows. We can even keep the old Kleopatra becuase it does not harm. Whether the "menu" is a container window or a detached windows can be decided by the user, like GIMP and other tools do this.

I tested this with OpenPGP and 2.4.3-beta19 on Windows. Worked nicely.

And of course we also need to adjust GPGME

We also need PROGRESS lines in gpgsm.

works, no KIO error. Gpg4win-4.1.1-beta317

Starting to understand KIO architecture a bit better. We can easily add more protocols if we want to. For now I have just added the file plugin. I tested with moving.

The code for the file Job etc. is definetly in there. I think it somehow tries to intospect supported protocols maybe even through dbus and this fails then. My current expectation is that we need to identify where this happens and then to hardcode some supported jobs / workers etc.

Yes most definetly I am looking it at next

Setting priority to high because this should be fixed before the next release.

Fixed by rGfcbb849c26e9: speedo: Fix regression due to switching from gcc 8.3 to 10.2 for zlib build.

Problem 2 comes from the fact, that gpg4win packages gpg 2.4.0, but the new archive code needs gpg 2.4.1.