Bug 89733

Summary: Better trust visualization desired
Product: [Applications] kgpg Reporter: Rob Kaper <webmaster>
Component: generalAssignee: Rob Kaper <webmaster>
Status: RESOLVED FIXED    
Severity: wishlist CC: debian, dev+kde, linux, sven.burmeister
Priority: NOR    
Version: 1.2   
Target Milestone: ---   
Platform: unspecified   
OS: FreeBSD   
Latest Commit: Version Fixed In:

Description Rob Kaper 2004-09-18 00:45:14 UTC
Version:           1.2 (using KDE 3.3.0, compiled sources)
Compiler:          gcc version 3.3.3 [FreeBSD] 20031106
OS:                FreeBSD (i386) release 5.2.1-RELEASE

It would be nice if KGPG could add to the appearance configuration different colors for full trust and marginal trust.
Comment 1 Rob Kaper 2004-09-18 00:52:06 UTC
It seems like it that right now, marginally trusted keys get the same color as expired keys, and the same is true for keys that are simply unknown.

I think good defaults would be:

Full trust: green
Marginal trust: greyish mint
Unknown: yellow
Revoked: red
Disabled/expired: orange
Comment 2 A T Somers 2004-11-09 14:22:05 UTC
I think it would also be usefull to be able to see where the trust comes from. Something like: you trust this key because it is signed by mr.X, who's key you signed.
Comment 3 Rob Kaper 2004-11-09 15:03:25 UTC
I've talked to Henk Penning about possible trust path graphing options. I'm not sure how much time I have and whether the algorithms/online services are fast enough, but it it's feasible I'll think about adding a detailed path view to Kontact/KGPG. Slightly getting offtopic for this wish though.

Which I should just fix myself.
Comment 4 Sune Vuorela 2006-05-04 20:36:16 UTC
Not only is it the same color for marginally trusted keys and disabled keys; when selecting 'hide expired/disabled keys' from the 'view' menu, it also hides marginally trusted keys.

I agree in the colors proposed.
Comment 5 Rolf Eike Beer 2007-08-08 13:20:10 UTC
Implemented in SVN, will appear in KDE4
Comment 6 Rolf Eike Beer 2007-08-08 13:21:37 UTC
*** Bug 88853 has been marked as a duplicate of this bug. ***