Access contact name and address book via DBus

[Danielle Foré]

On its own, Dexter is a great contacts app. But, if it could share with everyone else, it would be a killer app.

Dexter should have a dbus api that other developers can use to pull contact data.

[Allen Lowe (lallenlowe)]

this is what Postler will use

[Allen Lowe (lallenlowe)]

I started the module, and I now have one dbus service method to get a contacts name from an email address

[Allen Lowe (lallenlowe)]

I have a method to get a list of emails from a contact's full name

[Cris Dywan (kalikiana)]

If Dexter is opened from the 'addressbook' button in Postler's composer, I would love to see a dialogue, from Dexter, where I can click contacts and have them inserted into the composer as recipients. Perhaps by generating an ID randomly for the composer, and then Dexter sends a dbus signal with ID and name & address for each inserted contact.

[Cris Dywan (kalikiana)]

So we have these:

I org.elementary.dexterservice
 M get_emails (in v full_name)
 M search_contacts (in v search_string)
 M get_name (in v emailstring)

Problems:
- methods need to be CamelCased like other services
- get_emails is ambiguous → GetEMailAddresses
- ultimately we need a service file in case Dexter isn't running

[Allen Lowe (lallenlowe)]

ok, fixed the first 2 problems. I just have no idea how to create a service file.... yet

[Cris Dywan (kalikiana)]

I wrote a small Vala class representing Dexter and using the DBus service transparently. The class takes care of error handling and I plan to cache values on the client side to avoid redundant DBus calls. It might be good once finished to document the class as a reference or example for other applications on using Dexter.

I thought of using NewContactDialog via an icon next to contact names in the content view, so the user can directly add or edit contacts without interruption. For that, a method that does "add or edit contact, with email address and name (may be empty)" would be helpful. I think this should be one method for both to save Postler having to check the existence of a contact first. What do you think?

[Cris Dywan (kalikiana)]

More thoughts: NewContactsDialog is synchronously opening the dialogue, so without special handling Postler either freezes or asynchronously sends methods, which Dexter will collect and open one contact editor after another.

To make behaviour consistent with any client of Dexter, the method should return immediately while keeping the contact editor open. If invoked a second time, it should focus the existing contact editor. This I think would be most predictable for the user and match behaviour inside Dexter.

I'm uncertain regarding Postler's side since one window can't be modal in two places. Either subsequent clicks simply focus the existing editor. Or I could try to make the window react as if modal, though that needs testing.

[Allen Lowe (lallenlowe)]

ok, I will make these changes the next time I work on the dbus api

[Allen Lowe (lallenlowe)]

maybe we should close this bug in Dexter and start logging individual bug for each change needed??

[Cris Dywan (kalikiana)]

I filed bug 685537 for the above described feature.

Let's regard this as fixed in Dexter and I will take care of GetName and ShowWindow as the hsort-term goal on Postler's side.

[Cris Dywan (kalikiana)]

Initial Dexter class committed. Sender addresses with no name in the message overview will use Dexter to find out a name. And the address book button in the composer opens Dexter now.