This is still an issue. Since the double click opens a registry entry the working directory of Okular is Windows. Since it is the working directory of the explorer so that is unusable, but it should still be able to somehow take the location from the actually opened file and use that for a save file suggestion.

This works for me

Didn't you mention in another ticket that the work on this caused Kleopatra no longer to show the "Loading certificates,..." overlay? I still have that issue Kleopatra only shows its window once the keycache is fully loaded. I cannot find the ticket where this was mentioned anymore though.

Yes, It was not my intention that WKD should not work when searching for keys, when keyserver is None. Although such a search could be handled by just entering the email address in the recipient dialog in the file encryption widget to trigger a locate key or in the case of GpgOL to enter the recipient mail but I think that feature is very hidden / not really discoverable for users. And yes an improvement for the search Window in that case would be to then switch to "Enter Email" and use an email validator on the input field for example. So let us handle this as part of T6493

It is okay for you to start with option so "akonadictl --migrate" but I would suggest deleting the old DB only as an option. Especially if error handling is not 100% perfect there should be also an easy way to restore your old config.

I am heavily tending towards tagging this ticket as invalid as it sounds super individual, but I would like to understand the reason. Not sure how to triage this. Maybe lets give it a low.

Lets make sure that we look into this for 3.3

can be tested with beta312

Damn this actually happens with every file with a space. Why didn't our Gpg4win users,.. report this. 😐 I checked T6056 was part of the last Gpg4win release...

Our current PKCS#15 widget is optimized for RSCS cards.

@ebo if tasks have a parent please directly assign them the same priority.

This looks very similar to https://bugreports.qt.io/browse/QTBUG-85744 for me nearly all emojis work except the frowning face please do not investigate the font / emoji issue further.

The numbers in this dialog come from system font setting for monospace fonts and that might be broken for you. But you should then have problems in other applications, too. There is nothing special here and it works for all our other users.

I am closing this as resolved for now. I would need a completely new client or mess with the registry keys in which outlook stores the performance data to test this. But I would bet it still lists us as responsible for the slow start of outlook. But the time it will then show should now be 0ms since we absolutely do nothing anymore in our DLLMain.

I don't really know how to test this though since it tracks this over time and history. Let us see if my change fixes this, It may be that outlook does not measure the DLLMain (which I am pretty sure it does) but the actual COM initialization, in which case my change did nothing. But I don't see any way in which my change could make things worse.

I think outlook shows any native addin there. As you can see by the empty bar we don't really do anything in there to slow it down. But let me check if I can move the extremely little code we have in there somewhere else.

Oh, the user is actually asked with this? I wonder if that is something that is new now, I think so. I mean its been quite a long time that we added support for embedded filenames but 3.1.26 was also long ago.

In GpgOL at least I have an API call to query the display language of outlook. I just need to pass it through to gpgme early and forgot about it. Also I don't think this would actually help completely if gpg-agent is running already.

fixed in beta302

Fixed in the according repo. The sentence structure made it easy to just replace the word README with pkg-licenses.txt

Ah, forgot about the license text in the installer, I hope that I can do an easy search and replace.

by default we keep the unlocked secret key limited to this very tiny process (gpg-agent) which only does the secret key operations. That is I think the best decision. It is IMO not really a bottleneck since except for very small data bits the bottleneck is usually the hashing. What is your usecase of doing a thousand secret key operations (signing) on apparently extremely small data files a minute? And even then are you sure it is not your disk IO that is the bottleneck and it is in fact gpg-agent?

Well this depends of course. If the "Hard work" is the actual signing it depends a ton on your Key. An ECC key will go much quicker then for example RSA4096 but IMO the "Hard work" when signing is the hashing and that is done in parralel for extremely specialized setups you could run multiple gpg-agents in different homedirs with access to the same key.

Thank you very much on behalf of our S/MIME users. This also makes it easier for us in the frontend to show a consistent UI.

One proces per user is normal but the two for ebo-ad are strange. Especially the one with the multiple backslashes. I wonder where that came from. Can you try to find this out? e.g. have taskmanager open while you repeat your test and check when it comes up.

Fyi, Carl already, asked me to include that in our build so I will add this.

I created T6842 for the "Cleaning Kleopatra directories on startup" so that we can close this task once ebo confirms that all is fine. Usually I would close this task myself since I already tested it. But well we have QA now ;-)

Works nicely for me in beta300

I'm quite happy with that now. The only thing left to do would be to benchmark this, but to keep this as a an open task for that seems wrong.

Außerdem kann man das ja konfigurieren 😅

Yeah,.. keep the defaults and don't show them? :) With this screenshot you can send even the most friendly user running away. Monospace won't help there. And using different fonts in the same table is also ugly and monospace for the complete table is a no go for me since users should not look at fingerprints or keyids in this table view.

So this is done now to my liking. I took the pkg-copyright from GNUPG as a baseline at the top and then went through all other packages. It is mostly about licenses though and not about copyright holders, even the license information for some packages was weird to figure out. Let alone the individual copyright holders. So I don't think we can or should say "The list of other copyright holders". I changed that now "For a complete list of licenses see: "

Looks good now

This now works to my liking.

I read the documentation (and stackoverflow) as owner we have to close our handle before deleting the file. With FILE_SHARE_DELETE we only ensure that others must live with the fact that we can always delete the file, but since we hold an exclusive READ right (which we gracefully share with others) our handle needs to be closed. So the trick was just to CloseHandle first and then the file could be deleted.