The project's plan has changed -upon several requests- giving highest priority to the "conforming to vCard" task, which will be continued by the import/export to vCard task.

The main problem for the coming days will be creating "dynamic" detail views allowing (like OSX's Address Book):

- Visually creating an arbitrary number of entry fields (3 email fields, 4 phone numbers, etc.).

- Visually tagging each of this fields (home, work, etc.).

Is out there something like this anywhere on Chandler? I guess I will have to create my own specialized "blocks". In this case where to start?

Now some answers to past emails (all this topics are also on the wiki page):

Ted,

I think that you should spend some time thinking about how contacts

are linked to other items. We are going to have tasks which are

assigned to people (or waiting for someone to complete something

else), events which involve people, and so forth. One way of

looking at people/contacts is that they are a hub for organizing

information. I may have a meeting scheduled with Katie and want to

know which tasks I am waiting for her to complete so that I can

continue. I might want to know all the meetings that I have with

Bobby in the next week. I think that the interesting use cases

around Contacts revolve much more around data which is linked to

contacts, as opposed to stamping items as contacts.

I was thinking about a "see everything related to this contact" popup report.

Most items already create a bidirectional link to the contacts involved (event participants, item creator, group membership, etc.)

In the section "Implement the role of groups" you say "propagate

actions to group members". Which actions are you talking about here?

For instance sending an email to a group of contacts should be "propagated" sending the email to each individual group member as it is not possible to send the email directly to the group.

I see propagate as a "do this action for each member on the group".

Other actions don't need such propagation: if you add "Chandler_devs" group to your office hour event, the event should keep track only of the group and not their members as they may change.

While I agree that it should be possible (actually, it should be

trivial) to have contact items show up in the All collection, I'm not

sure that there is much utility in this. The All collection might

have quite a bit of stuff in it, which will probably make it hard if

you are just trying to find the contact for a particular person.

Also, once we get the dashboard view in place, contacts aren't going

to fit in well with that usage of the summary view area. It

should be very easy to create an address book collection which

contains all contacts, and this would certainly be a way to get

something up and running quickly. But I think that we are

ultimately going to want to have an optional pane which can appear in

any application area. I would encourage you to talk some more about

the design with Mimi. For Chandler 1.0 we are trying to support a

specific set of workflows and functionality, and we want the contacts

functionality to mesh well with what we are already planning to do.

I will detail this point on the project's page.

Mike,

Another thing I thought of as I was reading your tasks on the wiki page
was this: Couldn't Contact Groups be handled by using the existing
Chandler concept of a Collection? I'm not sure if this has been
thought of and rejected but my thought was that any Contact could be
added to any number of collections and that would allow you to
manipulate the Contact's membership separately from the actual Contact
data item.

Currently a ContactPerson and ContactGroup are subclasses of Contact abstract superclass, so you can use as you like single persons or groups anywhere.

To make groups also a collection would require it to be also a subclass of pim.CollectionItem, which shouldn't be an issue on Python right? While allowing drag and drop functionality.

However:

a) Adding them to the sidebar (or worse requiring groups to live there) doesn't look practical.

b) Allow adding non-contact items to the group collection? yes/no? why? Any collection should become a group collection if at least a contact item is contained?

I would also urge that you keep an eye out for the fact that almost
every item you have in a "normal" Contact schema will have multiple
occurances. Note I said "will" and not "could" - someone somewhere
will want 20 phone # while another person will want 20 addresses and
yet another will want 3 different name fields. Not that you need to
support that now, just keep it in mind

Yes, this will be part of the "conforming to vCard" task. However certain fields (as the name field) should only contain one entry to avoid vCard conflicts.

Creating the schema for this should be quite easy. The difficulties will come when implementing details view's "dynamic" behavior (like OSX address book's view).

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _


Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev

Re: [Chandler-dev] Contacts/Address Book project

Reply via email to