I tested it and for me the files are not deleted:

Since I have such a test card, I just tested it and the issue is indeed gone.

should this go into the upcomming VSD release?

Oh sorry, no that did slightly not make it in when I created the tarball for the current beta.

Now the Learn Certificates button is shown if at least one card key is unknown. And the list of certificates is shown if at least one certificate of a card key is known.

No change in VS-Desktop-3.1.90.295-Beta

Works on windows, too. VS-Desktop-3.1.90.295-Beta

works, VS-Desktop-3.1.90.295-Beta

works, VS-Desktop-3.1.90.295-Beta

VS-Desktop-3.1.90.295-Beta: now there is no button any more... So still no learn key possible.

It is now: https://invent.kde.org/pim/kleopatra/-/merge_requests/75
I realized that for Qt6 the include qtextcodec and setIniCodec must be removed. I should probably ifdef them to make merging more painless.

Should work now.

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.