GUI description

[dashohoxha]

No description provided.

[dashohoxha]

I am checking your changes here: https://github.com/EasyGnuPG/egpg/blob/3be3db66031d2f6b12e46f52931c70d1136f43bf/docs/gui-description.md

No problem that the pictures are not consistent. Their purpose is just to help us communicate with each-other, share our ideas and discuss about them. If you find something difficult to draw with Pencil, you can also make a hand drawing, then scan it with a smartphone and upload it.

After the application is finished, this application description will be converted to documentation, and then we will use snapshots from the real application, and everything will be consistent.

[dashohoxha]

If the person who signed the docs is not on the contact list, it should ask to search for him online. If found, should ask to save him on the contact list.

If the person who signed the docs is not on the contact list, we don't know his name and email address. I think that we only get "good signature from this key/fingerprint". This is the purpose of searching and finding him, to see his identity (name and email). Then, after finding him, we may also add him to the contact list, if we communicate often with him, so that we don't have to search again for him.

[dashohoxha]

Seal a file

When we seal a file, besides selecting the file to be sealed, we also need to select the recipients (from the contact list). How do I know this? I just look at the arguments and options of the command egpg seal. In the end we will just call this command to get the job done. We are using the GUI interface to get its options and arguments from the user, in a user-friendly way.

[dashohoxha]

Open a Sealed file(s):: we can also give an option to launch the file with default program

Maybe this goes a bit beyond the purpose and the boundaries of this application. But if it is an easy thing to implement, why not.

[dashohoxha]

Create a separate section for Manage Key and Manage Contacts, like this:

### 04. Manage Key
### 05. Manage Contacts

04. Manage Key

05. Manage Contacts

There will be a subsection for almost all the sub-commands of egpg key ... and egpg contact ...

[dashohoxha]

Manage Contacts::

I think that we should have a list of contacts that can be scrolled. It can be formatted as a table, with the most important fields (name, email, key-id, maybe fingerprint). Maybe this list of contacts can also be filtered (searched) by a matching pattern in the name or email, in order to simplify finding a contact.
This list of contacts should allow for selecting a contact. With the selected contact we can view his details (more details, including everything about him), or we can delete it, or certify it, etc.

[dashohoxha]

[dashohoxha]

[dashohoxha]

I don't think that using tabs for contacts is a good idea, because it makes the interface complex and difficult to build. We can just add a button "Add Contact" on the main contact page, and when it is clicked it opens the page for adding contacts, with several buttons/options for finding and adding a contact.

[dashohoxha]

In case that some page/window is difficult to implement with yad, we can try to implement it directly with GTK and Python: https://python-gtk-3-tutorial.readthedocs.io/en/latest/

[diveshuttam]

Hi @dashohoxha, Sorry for being unresponsive, I'll sort this thing out along with the other open PR in PGPG today. I was a bit unorganized in learning and other tasks for this week recently realized I have achieved a less (in terms of showable work) this week. I have created another project in this repo and will be organizing tasks there.

BTW thanks for these sketches will integrate them with the doc. 😄 .

[dashohoxha]

Take it easy. You have done well so far, and that's enough to get a pass. But you still have to work for about 2-3 more weeks. So, select the tasks that you find most interesting.

[dashohoxha]

About contact list and search (I am referring to the image here: https://github.com/EasyGnuPG/egpg/blob/3fff67edaa1c57ef9ab7ecb226c26256f86d7c1b/docs/img/contact-modify.png)

I think that this is one of the things that can make help a lot in making the application user-friendly. Maybe yad does not have all the features for implementing all the features the way we want, but we can try to build it by using GTK+Python directly (yad is based on GTK). Or maybe some other tools that are more flexible or advanced.

Referring to your sketch:

• I don't understand what is "S. No." and what it is needed for.
• The name and email are considered part of the uid (user id, or user identity), so I think that they should be presented together on the same column.
• Instead of giving the fingerprint (FPR), maybe just giving the key id is enough for the list. On the detailed page of the contact we may give the fingerprint as well.
• Usually knowing the expiration date is not so useful. More useful is knowing whether the key has expired or not, or whether it is going to expire soon (for example in less than one month).
• If we can use different colors for the lines of the table, we can use red for expired contacts and brown for the ones that are going to expire soon. This way we can eliminate the column of expiration.
• We can use colors for expressing the trust level too, for example green, blue, yellow, white, etc. This way we can also eliminate the trust column from the table.
• We can move the actions of Trust, Delete, Export, Certify, etc. to the page of the details of the contact.

The main function of the Contact List should be to select a contact. Browsing and filtering, and sorting are just to help with this. Selecting a contact is useful for example when we encrypt a file (and select the recipients). We also need to select it when we want to perform some action on the contact (mentioned above).

When receiving a contact from the keyserver (referring to this picture: https://github.com/EasyGnuPG/egpg/blob/4999468180e206884b86146ba4c9ca561e9aff13/docs/img/contact-add.png), we can as well scan his fingerprint from a 2D barcode (which is printed for example on a business-card).

One thing that may be useful about managing contacts is categories or tags (they can help in searching). However egpg or gpg does not support such a thing and if we wanted to implement it we would need to keep extra data. This does not look so feasible for the time being.

Another useful thing may be groups or distribution lists. If we communicate often with the same group of people, we can create a group of them and just mention the name of the group as the recipient, and all the members of the group will be recipients. Right now egpg does not do anything about this, but I think that gpg itself supports it somehow (if I am not mistaken). Anyway, we may thing about adding such a feature on egpg itself and on the GUI as well.

There is a similar situation about signing a file. The GUI description is a bit more complex than what egpg supports (it also describes keeping track of some metadata about the file, which egpg currently does not support).
Or sealing and signing multiple files, instead of just one. They cannot be implemented right now, but we may think of them as possible future improvements.

[diveshuttam]

I don't understand what is "S. No." and what it is needed for.

This was for giving an idea of number of contacts though I now think just a text/lable like 0 contacts selected of 21 will do a better job.

The name and email are considered part of the uid (user id, or user identity), so I think that they should be presented together on the same column.

Yup I think it would be better.

Instead of giving the fingerprint (FPR), maybe just giving the key id is enough for the list. On the detailed page of the contact we may give the fingerprint as well.

👍

Usually knowing the expiration date is not so useful. More useful is knowing whether the key has expired or not, or whether it is going to expire soon (for example in less than one month).
If we can use different colors for the lines of the table, we can use red for expired contacts and brown for the ones that are going to expire soon. This way we can eliminate the column of expiration.
We can use colors for expressing the trust level too, for example green, blue, yellow, white, etc. This way we can also eliminate the trust column from the table.

Cool.

We can move the actions of Trust, Delete, Export, Certify, etc. to the page of the details of the contact.

Sure

[dashohoxha]

I think that the structure of the application is clear, although not all the details have been discussed yet. So, we can start implementation and discuss the details as we implement them.