Re: Welcome to Gnome Contacts!

[Vamsi Krishna Brahmajosyula <vamsikrishna brahmajosyula gmail com>]

Hello all,

I am vamsi a developer and sysadmin. I have been following gnome development process since a few months

and am interested to contribute. 

On Fri, Oct 21, 2011 at 1:41 PM, Alexander Larsson <alexl redhat com> wrote:

Seems like a bunch of people are interested in working on Gnome
Contacts, hopefully they are all now on the list (or they can read this
in the archives). I'd like to welcome everyone and talk a bit about
Contacts. Also, it would be cool if everyone could introduce themselves.

I'm Alexander Larsson, I work for Red Hat doing gnomeish stuff and I did
all the initial coding for Contacts.

Here is the initial feature page for contacts:
https://live.gnome.org/ThreePointOne/Features/Contacts

Not a lot of stuff there, but it has some links to background stuff that
lead to the design. Also it has a link to the design page:
https://live.gnome.org/Design/Apps/Contacts

The design was initially a collaboration between several designers but
eventually it was mostly done by Allan Day, who can be considered the
design lead on the project. He also has a lot of other mockups and ideas
for contacts. Some of them can be seen at:

http://gitorious.org/gnome-design/gnome-design/trees/master/mockups/contacts/aday

I'm sure he can tell us about his current ideas.

Code-wise gnome-contacts is a pretty small project, about 6000 lines of
vala code. As such I'd recommend that you just read through all of it
(just skim over parts you don't understand, you'll get it eventually).
Also, Contacts builds to a large degree on libfolks and
evolution-data-server, so it would be a good idea to read up on how
those work.

Have not seen the entire code yet. 

I have built and ran the application from source. Looked at how main.vala , app.vala links to the rest of the sources. 

 

Some helpers for reading the code:

libfolks has the notion of "Persona", a Persona is a piece of
information about a contact from a backend, such as
evolution-data-server or telepathy. Each Persona is from a PersonaStore
which represents some kind of grouping in the backend (an addressbook in
e-d-s or an IM account in telepathy).

The main object in folks is the IndividualAggregator. It instantiates
all configures PersonaStores and takes the Personas in there and puts
them in Individual objects. Each Individual contains one or more
Personas, as the aggregator tries to link personas together. It does
this linking by comparing the data in the Individuals. Right now the
linking is done by:
 * the addressbook uid ("local_id") of e-d-s contacts
 * instant messaging addresses (for telepathy personas)
 * webservice addresses (for libsocialweb backend like facebook or
  twitter)

So, if any of these are the same (and the stores have the right trust
level) the aggregator links the personas together.

The aggregator also has a notion of the "writable" store, which is the
default store that we use to e.g. create new contacts, and where we
update data by default. This is typically an evolution-data-store store,
and we assume it has the ability to store all typical contacts
information (as opposed to e.g. telepathy personas that are mostly
readonly).

On the contacts side we have the ContactsStore singleton that wraps the
aggregator and creates Contacts object that wraps each Individual. This
lets us extend the Individual object with helper functions but also
things like cached avatar images.

The Contact object is also important for UI consistency because when
personas change in libfolks and the aggregator updates the linking all
the changed old individual objects are replaced by new ones (possibly
split or merged). When this happens we update the Contact object with
the right new individual, so that we can continue to show the right data
in the window. For instance, if you display a contact and unlink one of
the personas from it we need to ensure that the displayed Contact gets
assigned the new Individual representing all the personas except the
unlinked one and not the old non-existing Individual or the new
Individual for the now-split-out Persona.

I've had to punt a lot of things for the first release of contacts in
order to make the release date. But I've tried to put all the ideas and
todos that we've had in bugzilla so that we will not forget them. So I
would recommend everyone to read through the bugzilla component:

https://bugzilla.gnome.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=gnome-contacts&content=

Also, you might want to follow gnome-contacts-maint gnome bugs in
bugzilla to get updates when bugs change.
 

I released a 3.2.2 yesterday with a bunch of fixes for the most reported
bugs, so maybe its time to branch 3.2 and start new feature work on the
master branch. Although we still have to monitor bugs for 3.2 and
release bugfix updates as people start using it.

I've got some other stuff I'm working on right now, but in a while I'll
get back to Contacts work for 3.4, and the most important things I think
we need to do are (most of these are in bugzilla):

* Sync with the evolution guys to make sure the new e-d-s account
 configuration and handling works for us. See:
https://mail.gnome.org/archives/evolution-hackers/2011-August/msg00025.html
* Implement a new design for the link dialog, as the current one is a
 rush-job. Allan has some ideas here.
* Support undo for delete
* Support editing more field types
* Allow cropping when setting avatars
* Allow setting avatars from webcams
* Implement the application menu from the design (when gnome-shell
 supports it).
* Create a robohash-style avatar generator with a more gnomeish look
* Have some form of wizard you can run that lets you initially
 mass-link personas as suggested by the libfolks suggestions API.
 (Rather than having to do it for each contact manually)

Also, one optional thing we might want to look at is social web
integration. This was very much in the initial design for the contacts
app (i.e. integration with facebook, twitter, etc). However, legal
issues with the license agreements and practical issues with the API
keys made this problematic. However, perhaps as the google plus APIs are
starting to appear we might have a social website that allow nice
integration with free software. Something to keep a lookout for.

And I'm sure Allan also has a lot of ideas for design tweaks and new
features.

_______________________________________________
gnome-contacts-list mailing list
gnome-contacts-list gnome org
http://mail.gnome.org/mailman/listinfo/gnome-contacts-list

I better comment on the later part of the mail once I completely go through all the links and the source code. 

Thanks

-

vamsi