Re: Seahorse re: 2.4 Proposed Modules

[Jacob Perkins <jap1 users sourceforge net>]

On Mon, 2003-05-05 at 07:17, Andrew Sobala wrote:
> On Mon, 2003-05-05 at 12:48, MArk Finlay wrote:
> > > Like Havoc, I think that the UI needs to be aimed at "someone who wants
> > > to encrypt files and send them to someone else" instead of "someone who
> > > wants to have a graphical front-end to gpg."
> > 
> > I would disagree to an extent. Encryption is all about keys and anyone who
> > uses it knows that. You have to have a key to encrypt and you have to have
> > a persons key to decrypt something from them. You don't get very far in
> > encryption without that knowledge.
> > 
> > Thus a key manager makes perfect sense. I agree that the key manager is a
> > bad
> > place to go if you want to encrypt a file - nautilus is better suited to
> > that - but that
> > doesn't negate the need to manage keys.
> 
> Sure, a key manager makes sense. But I use gpg, and know what a key is,
> but don't need all the functionality replicated in a GUI. Most of the
> gpg functionality is specialist.
> 
> All you need is:
> 
> -> List of keys
> -> Import/export of keys
> -> Who it is; is it valid; sign it with a decent UI explaining what
> signing is
> -> Ability to create a key
> 
> You don't need:
> 
> -> The user to decide on "trust" values without an explanation of what
> he's trying to do
> -> A "User ID" tab with ciphers and widgets to sign and delete
> identities when every single widget is insensitive anyway
> -> Ability to add/delete subkeys

You don't need it, but if the functionality is there, why not make it
easier. If someone wants to manage their keys, they need to have as much
control over them as possible. Yes, the interface does assume that the
user basically knows what they are doing. I'm not sure if this is the
best approach, so any suggestions for UI improvements are welcome.
--