People GUI should support vCard contacts

[heidi]

Ticket for this GCI task: ​http://www.google-melange.com/gci/task/view/google/gci2012/7949203

A mockup should be created so that the current UI for People could be extended to support vCard contacts.

[mmadia]

hi. please attach this as individual files. compressed archives are discouraged. thanks!

[X512]

I think that "manage fields" window is too low-level and not user-friendly. Removing items could be done by setting empty values instead.

[stippi]

First of all, I think this ticket might be a duplicate. I have this faint memory that this was already requested in a ticket.

Secondly, a while ago, I rewrote People to generate the UI based on the defined attributes of the Person file type. In other words, when the user goes into the FileTypes preflet and adds or removes attributes in the Person file type, the People UI will adjust to the changes. People being more or less a demo level application, I think this is how it ought to have worked in the first place, but never mind. In any case, the "manage fields" functionality is already there by being delegated to FileTypes. (There may even be a menu option in People which launches FileTypes, don't remember.)

In the other feature requrest for vCards, I think someone suggested to let the content of Person files be in vCard format. To me, it sounds like a good approach. It would duplicate the information in the file attributes and the file content, with the potential of both places becoming out of sync, yes, but it would not be any different from how Mail files are stored right now. The user basically just uses tools to view and edit those files, and those tools just need to be aware of the content duplication. Of course if you change the birthday in Tracker and Tracker doesn't update the vCard content, then it's the same as when changing the subject of a Mail in Tracker and the Mail contents not actually updating. Some of it can be prevented but also less convenient by making attributes non-editable. But for the majority of use-cases, it should be much easier to handle than the user needing to export as vCard from within People.

[richienyhus]

Would the other ticket be #7274?

[Barrett]

Just to let you know i've not abandoned my gsoc project, i've continued to develop it during the last 2 years.

While i think useful for the actual People the possibility to edit fields from filetypes, i think it's a completely bad approach for a VCard based Person format. VCard is a lot complex, and besides that some fields are just "as is", the format already specify a way to define custom fields. Basically any field put with the X- prefix is an extension, i don't think there's any control on it. So if for example people add an attribute for every field we easily end up with a messy attribute list. In my actual implementation, low level things are all handed by the translators, so i think the best approach is to split the formats, making the actual person format behave as stippi defined it, just for compatibility reasons. The "new" Person format that i would call "vPerson" should behave differently. You have a basic set of fields (such as MAIL or FN), which the user can't modify, and some extensions which the user should be able to configure in some way. I think the best approach is another tab, named maybe "Additional data" or something similar, where the user is able to define an extension by just clicking a button "Add a custom field". Those will result into a low level X-WHATEVER field, where you named it in high level "WHATEVER". Another option is to let the user select from People itself which fields will be turned into file attributes.

This is just an option, from another point of view, People could just don't care about extensions, and just let them show in the app, leaving to expert users the work to edit the vCard file and add the extensions they want. Obviously some common extensions are already supported out-of-the-box by my own version of People, X-GENDER is the first extensions that comes to mind, for extensions like it, the treatment will be just as the other standard fields, i think there are no doubts about it.

About attributes, i would just stop with the idea of making them the container of informations, as said one just should not edit the attribute informations, which in my opinion are provided to make easy to search not to edit the contacts in Tracker, in any case a translator for the actual format is provided, and one could just trade the new complete format with the old simple customizable format. Also i'm not sure that every vcard field should be turned into an attribute, just because it could easily become messy. In any case, to configure attributes from FileTypes is not so easy and transparent for the user. So from my vision of all that, the vcard translator, will just overwrite attributes without any care of the content in it, since it's just a simplified representation of the vCard fields.

Talking about my actual implementation, i just got lost with the idea of making the People GUI simple, and that's why i wanted a new mockup, i think the tab-columnlistview approach is ok, and it would take a few hours for me to implement it.

About the BContact format, it's just actually a lot similar to vCard, since it's a from scratch work, i just feel convenient to adhere to vCard where we can. Let me show you an example :

in vcard you have the N field that contains name and surname separated by semicolon (N:John;Doe) and it's represented as a B_CONTACT_NAME (a BStringContactField specifically) field containing the same string.