Existing file. I downloaded a pdf into the local Download folder of my Windows-VM and worked with that.

Is the document loaded from an existing file on disk or directly as a url from a remote server? http(s) or windows share ?

We should really fix that quickly.

On VS-Desktop-3.1.90.287-Beta I get a suggestion of c:\Windows for saving the signed document, not the users directory any more.
So its gotten worse instead of better...

It may make more sense to add the Craft Windows job instead of the Windows CI job because the latter doesn't use Craft, so that everything you did for Craft doesn't help with the Windows CI.

I guess this was high priority.

This is very much unrelated to any GnuPG code so I can say this is resolved for Gpg4win, too.

because I did not test with gpg4win yet. And I'm not familiar enough with the code base to say that it does not need to be testet with 2.4 again. Feel free to close it and move to done in the gpgcom workboard if you think its resolved for good.

So why not resolved?

For me it is like if you open a save file dialog. You want it to remember where you saved a file the last time you saved it. But if you just browse around and cancel it, it should not store that location.

We don't change settings. We just remember what the user used the last time. That we save this information in the same file as settings doesn't make them settings. (It might be more correct to save last used keys/options in the state file where window sizes are saved since some time to better separate this information from actual settings.)

ok, done for now.

is now hidden in VS-Desktop-3.1.90.287-Beta

Assigned to me for testing.

I do not see any gpgsm processes appear in the task manager on windows when viewing a .eml file which was smime encrypted with the mimetreeparser.
I guess this is enough to move this to done for VSD

Similar fix for KMail/Messagelib https://invent.kde.org/pim/messagelib/-/merge_requests/153

I have added a workaround and tested it on Windows. Works now for me, including T6566.

I think cancel should not save the settings. A case of "uuuh I clicked something wrong and now I am confused" -> "Cancel" -> "Phew everything back to normal". Is more valid then just looking around, canceling and then coming back later and expecing the same state. I would say this resolved.

Looks like Werner fixed this by avoiding unnecessary file changes in the agent.

We always try to update the stub files because meta data of the key material might have changed due to the use on another box. On Windows the file system watch might be triggered by the remove of a key file right before writing it (cf. the usual Windows rename file problem) which is the cause for the loop. The new patches now detect whether a key file actually changed and avoid writing it back to disk.