"Exclusive user" sounds a bit odd and could still be misinterpreted. A native speaker would probably say "Are you the sole user of this secret key?“ or (even better and shorter) "Are you the only user of this secret key?"

Background of my "reminder" comment: we were discussing to establish a sane workflow for sharing keys. Which is quite commonly done e.g. for functional mail addresses, but usually people seem to share the whole secret key which is not advisable. We would want people to only share subkeys for that purpose.
It was the case that somebody gets a subkey for such an "offline" primary for the first time which I was thinking of.

Details should be the first action (since it's likely the most often used action by people who don't know about double-click). And I'd move the "destructive actions" to the bottom. And there are way to many separators.

In T7502#198141, @ebo wrote:

Reminder: we have to keep in mind the workflow of the import of secret subkeys. Do we need different behavior conditional on "is primary key present" or not?

Reminder: we have to keep in mind the workflow of the import of secret subkeys. Do we need different behavior conditional on "is primary key present" or not?

With my initial suggestions, modified by:

Another thing (should definitely go into a new ticket if we want to do something regarding this):

Okay. We now replace the standard Breeze icon of kleopatra with the red head for vsd and with a new blue head for gpd. The replacements are used for the About action and in the About dialog, but kwin (X11) insists on using the standard icon as window icon. And the system tray also shows the standard symbolic Breeze icon instead of the replacements. strace shows that the replacement icons embedded in the AppImage are loaded. No idea why kwin and the system tray still use the standard icons.

Shorter version:

Possible explanation text for the user regarding the background of the question (probably to long):

FWIW, for gpd and vsd we should use a different icon (blue head for gpd and red head for vsd)

Kleopatra with Breeze style:

I would keep the "create group", too.

In T7515#198012, @alexk wrote:

Regarding the suggest list I would change the following:
but keep:

• Enable/Disable Certificate

Regarding the suggest list I would change the following:

Needs to be tested/verified by other developers. In short you do

./autogen.sh
cd packages
./download.sh
cd ..
./build.sh --appimage --builddir=...

If you omit the --builddir=... option then ~/b/SRCDIRNAME-appimage will be used.

Building an AppImage including Kleopatra and Okular works now (again) in the gpg4win-5-branch.

aheinecke: Yeah, but I did quite some changes to build.sh for a real out-of-source build (w/o copying files)

Just so that its not overlooked and you are meaning something different. But I had the Qt6 / KF6 branch working with the --appimage parameter.

Fixed.

In T7515#197774, @TobiasFella wrote:

I'd suggest removing:

I'd suggest removing:

If a single OpenPGP certificate is updated then we now show the same detailed information for the update from WKD as for the update from a keyserver, i.e. if the certificate didn't change via WKD then we say so.

I think there's some confusion.

changed the workboard to gpd5x as this is still the case in Gpg4win 5.0-Beta versions.

Gpg4win-5.0.0-beta32
Works!

Gpg4win-5.0.0-beta32:
The remaining attempts are listed:

You need to be asked this question when you restore the backup of all of your keys or when you migrate all your secret keys to a new computer.

The situation seems to be even more complicated: If I click "yes" or "no" in this dialog, I *do* get asked for all certificates that are being imported. If I click "Cancel", no more dialogs show up.

I'm not sure what Kleopatra should do differently. Kleopatra relies on the error messages provided by gpgme which in turn relies on gpg's status messages.

FWIW, If a fix is really required for gnupg this will be done for gnupg26 and not for gnupg22. However, it is mostly a kleopatra issue.

Hm, "Names for the certificate" seems wrong to me. Shouldn't it better be "Names in the User IDs [of this certificate]"? I would leave of the part in [] as redundant. Likewise for the mail addresses.

Thinking about this some more, i came up with some more ways of showing some nice-to-have information in the tooltips:

works with VS-Desktop-3.2.94.481-Beta

works in VS-Desktop-3.2.94.481-Beta. The "Trust Root Certificate" is no longer offered in the context menu.

works in VS-Desktop-3.2.94.481-Beta

"Tested" with VSD-beta-478, looks as expected