Carddav
Thatoo opened this issue · comments
Problem
Elementary os can't sync contacts with nextcloud or Baikal or other carddav platform that allow us to sync contact with our smartphone.
Proposal
It would be nice to be able to set our carddav sync with our a platform such as nextcloud and manage our contacts from the elementary contact app and be able to use them in the mail app for example.
Prior Art
Not so sure but in Linux Mint I guess it uses evolution to set everything right away, caldav, WebDAV and carddav. I personally use cardbook extension of Thunderbird when I run Debian.
I was pleased to try again elementary os and I advised it recently with one warning only... No carddav functionality. Hope it will come.
I'd be glad to do test with nextcloud carddav if it can help.
For future reference:
While fixing some issues with elementary Tasks in Online Accounts, I came across the contacts_url property. Setting it's value seems to enable contacts sync for CalDAV backends.
However, this needs further testing, since it also seems to have some other side effects.
For this to achieve the following tasks need to be completed:
- Make the Online Accounts Plugin support CardDAV, read: add a CardDAV resource to EDS (see E.Source.remote_create).
- Make Contacts app use EDS as backend, also see aggalex/Contacts#24.
For the first one it seems some more general plugin structure for new types of "online accounts" is missing currently. That probably would be a nice to have.
Examples of how to handle the (not very intuitive, sorry to say) API:
- Create: https://github.com/elementary/switchboard-plug-onlineaccounts/blob/main/src/Dialogs/CaldavDialog.vala#L386-L415
- Read: https://codeberg.org/Letterus/addr2snom/src/branch/main/A2SEvolutionDataService.m#L67-L172 (ObjC there)
- Work on contacts: https://valadoc.org/libebook-1.2/E.BookClient.html (that one looks easy)
For reference/to recheck: Resources added using Evolution (the app) do not seem to be added to EDS? A CardDAV address book added via Evolution cannot be retrieved using the way described above. Is this the expected behaviour?
There is an example at EDS docs as well where the most important part comes at the very end (https://developer-old.gnome.org/eds/3.22/eds-cursor-example.html):
ESourceRegistry *registry;
ESource *scratch;
ESourceBackend *backend = NULL;
GMainLoop *loop;
GError *error = NULL;
EBookClient *ret_book;
loop = g_main_loop_new (NULL, FALSE);
registry = e_source_registry_new_sync (NULL, &error);
if (!registry)
g_error ("Unable to create the registry: %s", error->message);
/* Listen to the registry for our added source */
g_signal_connect (
registry, "source-added",
G_CALLBACK (cursor_data_source_added), loop);
/* Now create a scratch source for our addressbook */
scratch = e_source_new_with_uid (CURSOR_DATA_SOURCE_ID, NULL, &error);
/* Ensure the new ESource will be a local addressbook source */
backend = e_source_get_extension (scratch, E_SOURCE_EXTENSION_ADDRESS_BOOK);
e_source_backend_set_backend_name (backend, "local");
/* Now is the right time to use the ESourceBackendSummarySetup to configure
* your newly created addressbook. This configuration should happen on the
* scratch source before calling e_source_registry_commit_source_sync().
*/
/* Commit the source to the registry */
if (!e_source_registry_commit_source_sync (registry, scratch, NULL, &error)) {
/* It's possible the source already exists if we already ran the example with this data server */
if (g_error_matches (error, G_IO_ERROR, G_IO_ERROR_EXISTS)) {
/* If so... then just call our callback early */
ESource *source = e_source_registry_ref_source (registry, CURSOR_DATA_SOURCE_ID);
g_clear_error (&error);
g_return_val_if_fail (E_IS_SOURCE (source), NULL);
/* Run the callback which creates the addressbook client connection */
cursor_data_source_added (registry, source, NULL);
g_object_unref (source);
} else
g_error ("Unable to add new addressbook source to the registry: %s", error->message);
}
g_object_unref (scratch);
/* Give EDS a little time to actually create the ESource remotely and
* also have a copy if it cached locally, wait for the "source-added"
* signal.
*/
if (address_book == NULL) {
g_timeout_add_seconds (20, cursor_data_source_timeout, NULL);
g_main_loop_run (loop);
/* By now we aborted or we have an addressbook created */
g_return_val_if_fail (address_book != NULL, NULL);
}
/**********************************************************
* Ok, done with creating an addressbook, let's add data *
**********************************************************/
load_contacts (address_book, vcard_path);For reference/to recheck: Resources added using Evolution (the app) do not seem to be added to EDS? A CardDAV address book added via Evolution cannot be retrieved using the way described above. Is this the expected behaviour?
If you want to tinker with EDS configuration, you need to make sure to install Evolution from *.deb package - if it is installed as Flatpak, it is sandboxed and does not have access to the system's configuration.
Any update on that feature?
I saw that Elementary OS 7 is supporting caldav now. What about carddav?
Any update on that feature? I saw that Elementary OS 7 is supporting caldav now. What about carddav?
@Thatoo Thank you for your comment and your request. Everything written above is still valid I think. We'd need somebody having enough time to implement CardDAV for the Contacts app using Evolution/EDS.
If somebody has time I'd back this work with some bucks. Maybe @danirabbit would not mind thinking about a funding project to back a contract based work? I think there is high demand for a Contacts app.
I don't understand, the Gnome Contacts app already exist and it does have Carddav support : https://apps.gnome.org/fr/app/org.gnome.Contacts/
Why making a new app?
@Thatoo elementary apps aim to be highly integrated visually regarding the HIG.
It would be possible to port GNOME contacts technically and adjust its user interface optically. But still somebody has to it.
GNOME Contacts also relies of libfolks which the author of elementary Contacts declined to use for his app, understandably.