I cannot reproduce this with Version 3.2.2.2405000+git20240712T143635~6033869e1. I open the Details window, go to Subkeys, right-click table header, select Keygrip, close Details window, open it again, go to Subkeys, Keygrip column is still shown. Even after restarting Kleopatra.

With Version 3.2.2.2405000+git~ (Gpg4win-4.3.2-beta41) II can add a keygrip column to the subkey details. But if I close the details window and open it again, the column are no longer selected.

The easiest solution would be a setting for gnupg. Then Kleopatra would just error out. But, as Andre rightfully points out, people will work around this restriction. Users are incredibly creative.

Just to clarify: I didn't say that we should remove the coloring/font style of certificates. I just said that I vote for removing the UI for changing the colors and font style.

The data looks garbled:

Since Kleopatra does not suppress the pinentry prompts think there is even one additional question at least for S/MIME. So it asks you once from Kleopatra and then you are asked by GnuPG.
AFAIR we had discussed this in the past and also came up with the Idea that the user should type in DELETE. That dialog should then come from GnuPG I think so that it is the same.

gpg makes it pretty hard to delete a secret key; thus having a (user settable) option in Kleopatra makes a lot of sense to me.

No. To solve that problem we have the revocation certificates autogenerated in the GnuPG home folder and which are kept of course when a user deletes their key.

Mh, no, on the other hand the style is useful in the "All certificates view" to make distinctions based on multiple parameters. "Like trusted S/MIME root certificate" and it is useful to see that right away instead of using the filters. So my vote would be to clean it up, but keep it in general.

Experiences from customers are that people create their certificate, upload it to a server. Then they notice a mistake in their name and delete the whole cert and upload the new one. Now there are two certificates on the server. This is only one example of what can go wrong. Admins want this not to happen and that's the reason for this feature. More warnings will probably not solve the problem.

Hard to decide as we have no data how much it is used. :-/ But I tend to agree here. We should not loose sight of the fact that Kleopatra should be more of a diagnostic tool and provide all the information a user might need to solve their issues with signing, verification, encryption and decryption. Kleopatra is not something a user uses so often that they play around with appearance or so like they maybe would in a MUA. Certificate management is just an unwelcome side effect required for crypto. But users do not want to do certificate management for its own sake.

I vote for removing the UI for configuring the appearance of the certificate categories completely from Kleopatra. This would solve all usability problems in an instant. People who want to go crazy with colors can edit the rc file.

You could use colors, fonts, icons to mark any certificate you want instead of having to use tags and filter by them. You could even put their company logo on certificates of your communication partners.

As it was a fresh install of a gpg4win test version I used: yes, common.conf was not only supposed to be there, it is and keyboxd.exe is shown in the task manager.
But I think it not only needs to be solved for keyboxd, as our VSD customers don't have that.

In T7212#188683, @ebo wrote:

We might also consider going all out and allowing a configurable appearance on a per certificate level. Then this feature would see an increase in use for sure. But it should work without issues, in that case, as then people will notice them…

From the support angle, the worst of these issues is that the default will not be restored for VS-NfD. But then: nobody has inquired about that yet…

The high-contrast modes disable all colors, but for normal dark modes we might have a problem with some of the predefined colors.

Uhm this is a task I have with High priority. I do not know what to do here or what it is really about. -> Invalid.

Yes, this is all something that is ugly. The VS-NfD colorization was done by justus winter back then since I fell sick and it was one of his first and only tasks in Kleopatra. So it is normal I think if that is implemented differently then other things. And in general the whole appearence configuration is I think rarely used. To me it always felt like a "We add it because we can." feature. But also with this mix of filters defined in a preinstalled libkleopatrarc and additionally hardcoded filters it is all strange.
Well colors and so on should be changeable for accessibility of course.

Wouldn't this usecase be better solved if we could highlight trusted-keys in the keylist better? I mean not trusted-keys as in "this key has full trust" but this key is one of 1-10 (In real life the most we saw was 5) which is configured as a TrustedKey

TrustedKey1
The value specifies a fixed trust root (trusted-key). If more than one trust root is required, the entries TrustedKey2, TrustedKey3, TrustedKey4, TrustedKey5 may also be used. Take care to specify the 40 hex-digit fingerprint of those trusted keys.

The problem here is that Kleopatra could do that of course, e.g. after importing a file. But this has to be done by the GnuPG system to handle all the automatic cases etc.
I leave this up for triage, since I am not sure if this is a bug, or a feature request. @ebo I believe you said to me that you tested this with keyboxd? As my answer would have been that keyboxd would be required for a proper solution to this.

I think we can close this as Wontfix since it is our opinion to wont fix this issue. If there should be more prevetion of accidents it would probably be better to have the user type in "DELETE" or "YES". Anything else then another click confirming a popup. Since this will just be clicked away through muscle memory. This came up again in T7211: Kleopatra: configuration option to prohibit deletion of certificate with secret key

In MMO Games this is usually handled that a player either has to type in "DELETE" or type in the Characters name to delete the character. At least in the last games I played.

KWin has a script called "Dim screen for Administrator Mode" which mimics the windows behavior.

I would give this low priority. There is no way to prohibit that except if the user has no deletion rights on the file system. There are already multiple dialogs asking the user to confirm the secret key deletion. A user could by the same logic "Free up some space" in their local home directory and delete %APPDATA%.

Yes this was just a performance thing and had no other UX reasons so we can change it.

In T7206#188622, @aheinecke wrote:

With the imports I also find the imported certificates tab more useful then the number. Since I think that adding full blown keylist views would be a bit of an overkill I personally would probably just use an expandable widget in the notification and work with lists of updated users ids / summary lines.

But since this also would be some custom code maybe it would be better to show a full list view of the updated certificates?

Ok, well in the days were did not have that much development power on Kleopatra and GpgME refresh keys just took the lazy part and offered the gpg output in a window. I still think that can be useful (e.g. diagnostics) to have as an additional details button. Especially in case of errors. What very often happens here is that the online access gets blocked somehow maybe even only to some servers. I am not sure if the numbers are really a helpful information. Please keep in mind: What do we want to inform the user about? If the user just sees some numbers is this really helpful? I think the user might want to either see which certificates were updated and which werent or if there were any problems updating. Personally I would find the information "what" changed the most important but that seems to me like too much icing on the cake. Like

• Changed expiry: foo@bar.baz <0xbadbeef> boo@bar.baz <0xa....>
• New signatures:

....

• Changed subkeys:

....