High priority because multiple running dirmngr can cause interesting problems.

Merge request was merged for both MimeTreeParser and MessageLib

See also T6465

I thought I had tested this, too. But apparently I lost track of my versions and did not.

Ah sorry i did not read your two messages that analyzed this correctly before I wrote my comment I had not refreshed the page.

Sorry, I didn't really pay enough attention when I reviewed this, but I thought you had tested this.

Nevermind, I realize the problem since we are in the constructor KAboutData::setApplicationData is set when the constructor returns. So it does not makes sense for us to already call KAboutData::applicationData in this constructor and update it in the constructor only to have it overwritten when the function returns. Wit the constructed KAboutData object. Doing it in a thread works because then the thread is run after the constructor initially set the the application Data.

updateAboutDataFromSettings is calling the static KAboutData::applicationData() and KAboutData::setApplicationData() from the c'tor of AboutData, i.e. before the AboutData has been fully constructed and has actually been set by the setApplicationData() call in main(). And then the call in main() overwrites the application data set by updateAboutDataFromSettings. Before the change it worked because the thread called updateAboutDataFromSettings after the application data had been set in main().

So this is weird to me to describe. After merging: https://invent.kde.org/pim/kleopatra/-/merge_requests/72 It would no longer use the updated KAboutData from updateAboutDataFromSettings in the loadBackendVersions code. There it would see the original aboutdata and then set that with the added otherText.

You are right. Forget what I wrote. I had forgotten that the Windows CI images use Craft to install the non-KDE dependencies.

With https://invent.kde.org/pim/mimetreeparser/-/merge_requests/26 it's possible to toggle between the plain text and the html content

In rLIBKLEO6be67ced16872c2510b6a425bcbda04f2596c671#81774, @ikloecker wrote:

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.

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.)