@jmrexach I think I undestand now @TobiasFella can you have a look please?

Hi,
To reproduce this just change an item in the filter list: The contents of the window changes but NOT the name (title) of the window (only in the leftmost tab).

Yes we could add that. Okular has this actually. For now we were Happy to go with the system default in the last version :)

I cannot reproduce this. If I right click the tab I can rename it just like every other tab. The tabs do not change their names based on the current filter that is used that is only their default name. And the default for the first Tab is "All Certificates"

Yes, basically these actions check if the underlying document is there and if not they make themself invisible. But then they should not be in the menu in the first place. But I believe the impact of this is rather low.

This seems to depend on the Platform theme. Under Windows I get the same results as you on linux It works fine with me

I need to come up with a better strategy here. --refresh-keys is a very useful command and it should do what the user expects. Maybe we can adjust the behaviour iff we detect that there is an LDAP keyserver.

Mh, the problem is that this is really a speciality feature which KMail currently has, that you can configure for a contact to prefer S/MIME over OpenPGP even though you have both keys.

I'm not sure how to approach this.

Moving back to WiP and setting status to Testing. Moving to QA shall be done when an installer to test this is available. See https://dev.gnupg.org/w/gpgcom/

Seems to be a small problem with the regex used for extracting the gpg4win version number from kleopatra's version number. See https://invent.kde.org/pim/kleopatra/-/merge_requests/117/ for fix and details.

My suggestion is to define all filters in libkleopatrarc instead of defining some filters in the C++ code.

Isn't the kleopatragroupsrc just such a config file?

Implemented: https://invent.kde.org/pim/kleopatra/-/merge_requests/116 and https://invent.kde.org/frameworks/breeze-icons/-/merge_requests/323

Quick hint how to test a fix given that the versions.gnupg.org currently does not carry an entry for gpg4win.

These actions/commands or, more precisely, the documents those commands show, are only available in the commercial GnuPG VS Desktop release.

Ingo came up with the idea to put all the filter definitions in a config file in the GNUPGHOME.

The validity column does not contain that information in case only the encryption subkey has expired.
As is the case if people extended an expired keypair via Kleopatra with VSD up to 3.1.26.

This is basically done although not exactly as proposed here.
But WKD and Keyserver search are now combined. With WKD search only if you configure keyserver "none".

I have disabled update notifications for now. We can reenable them with the next Gpg4win release when we fix Kleopatra to again query for the Gpg4win version and not for the Kleopatra version. I am leaving this open to fix just that in Kleopatra. If you now go under help -> check for updates it won't show you an update anymore.

I give this low priority because in my view users should not initiate file encryption by launching Kleopatra. I still hope that most users should not even realize Kleopatra exists and only interact with it through the dialogs. Putting the action in the toolbar is also already possible through configure toolbars. I rather would find it more confusing to have two encryption buttons next to each other.

Giving this the same priority as the parent task.

Ah, sure that also makes total sense, I thought you wanted it disabled if it did not extend all subkeys.

It seems I did not express myself clearly.
I would prefer it if the "with subkeys" checkbox could not be enabled in case it won't extend any subkeys anyway.
With a bonus tooltip.

You have to restart once. Then it goes away. We can't do much about this since we load the icons etc. at startup and don't have dynamic color changing. It might be better with the next Version which will update our UI Framework but no promises. I leave it open for now so that is a known issue.

Ikloeker is our resident accessibility expert and Kleopatra has a certificate for accessible software so I agree that we should not change it. Or is there a specific issue / condition for you that makes this extra hard to read?

For accessibility the contrast between text and background must be high. Therefore, I don't think we should change the color. In any case, you get what you asked for: A dark (green) background color.

In the Certificate Selection Dialog where the user controls the filter it makes sense to apply them also to key groups. The only question is how, i.e. with all_of or with any_of? I'm leaning towards any_of, e.g. if "OpenPGP Certificates" is selected then all key groups are shown that contain at least one OpenPGP certificate. This would also address my concern that key groups could be hidden if they contain an unsuitable key because they would only be hidden if all keys are unsuitable.

I need to investigate why this happens. Maybe we can as a workaround fix it on our server side without the need for a new update.

If things start unexpectedly you already went to the console to change it or already changed it in the subkey view. Otherwise it is too intelligent for my tase since I have subkeys for example with different expiry dates. But nearly all users won't have that. I think the current solution is good. But @ikloecker can you change it please to +/-1 one hour you are right that the time window is too short.

I have the same problem too English language and Italian language