[project idea] Improve the usability of GnuPG CLI

[Bernhard Reiter]

Hi Dashamir,

Am Donnerstag 16 August 2018 01:01:10 schrieb Dashamir Hoxha:
> Since this GSoC term is almost over, I would like to share
> a few project ideas that might be used on future terms.

note that some people criticise the Google Summer of Code program
for 
a) mainly helping Google to recruit people
b) often creating results that are a one shot and are more a burden to the 
Free Software initiative they are trying to contribute to.

This is the reason why Werner stated 2017-12 that he will not support it.
(https://lists.gnupg.org/pipermail/gnupg-devel/2017-December/033306.html)

> This project idea originates from this discussion:
> https://lists.gnupg.org/pipermail/gnupg-devel/2018-July/033852.html
>
> The idea is to write a CLI wrapper for the `gpg` command
> (in Bash, or Python, or something else) that improves the usability
> of `gpg` by trying to imitate the style of the `git` command.
>
> Basically it should do something like this:
> - Clearly separate the commands from the options and arguments.
> - Use bash autocomplete whenever possible.
> - Create a separate man page for each command.
> - Give contextual help when user seems to be lost.
> - Etc.

Agreeably the command line interface of gpg is not as good as it could be,
especially if you consider modern complex command line interfaces.
In principle all research to improve GnuPG is welcome.

Once a project is proposed, it should be asked if  itis worth the efforts
and if it should be done compared to what else could be done in the same time 
by the same people.

From my perspective the idea of improving the interactive command line 
interface of gpg in a more radical way is doubtful. 

For once the current command line interface is historically grown and 
(unfortunately) used in a number of scripts. There would be high learning and 
changing costs if it would become incompatible or even extended by many 
commands. So the old interface will have to be preserved. It does not seem 
feasable to maintain two interfaces in the long run. So we probably are stuck 
with the pros and cons of the current interface style.

As second point I don't think that the gains are on the top of the list of 
making gpg better. Many people will use gpg just as engine and not directly 
because gpg is about emails and files. Those are handled best in file 
browsers and email clients. File handling is done a lot on the command line, 
so the interactive interface can be used there of course. Many other command 
use a style comparable to gpg, and gpg is a complex application so there is 
some learning necessary anyhow. If people have time there are much better 
places to improve the user experience: like help email clients to make use of 
the first steps of WKD.

Best Regards,
Bernhard

-- 
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190319/76a3508a/attachment-0001.sig>