GNOME Bugzilla – Bug 663715
Take advantage of the ContactInfo support in Folks
Last modified: 2018-05-22 15:11:23 UTC
Since fixing bug #657602 (included in Folks 0.6.4), Folks handles read/write ContactInfo for Telepathy personas. This includes phone numbers, birthdays, etc. (all fields that the Empathy Personal Information dialog supports). So Empathy should be able to clean up some code by just reading and writing the FolksTpfPersona phone_numbers, etc. properties instead of having to dig into their TpContacts.
Should we use the "specialised" API (FolksPhoneFieldDetails, etc) or use FolksAbstractFieldDetails directly? We also need to Idle specific fields such as x-idle-time for example. Will I get those from Folks as well?
(In reply to comment #1) > Should we use the "specialised" API (FolksPhoneFieldDetails, etc) or use > FolksAbstractFieldDetails directly? Use the derived classes in most cases (AbstractFieldDetails is an abstract class, so you can't instantiate one). For now, just use the AFD symbols for the generic details (eg, to get the 'value' field). In the future though, you may wish to refer to AbstractFieldDetails symbols when you're handling AFD-derived values in generic ways. Eg, if (FOLKS_IS_ABSTRACT_FIELD_DETAILS (fd)) { GType value_type = folks_abstract_field_details_get_value_type (FOLKS_ABSTRACT_FIELD_DETAILS (fd)); if (value_type == G_TYPE_STRING) handle_afd_str (fd); else if (value_type == FOLKS_TYPE_POSTAL_ADDRESS) handle_afd_postal_address (fd); } Though note that folks_abstract_field_details_get_value_type() hasn't been merged to master yet. It's in my search branch, but I'll try to mainline it sooner to simplify some of this code. > We also need to Idle specific fields such as x-idle-time for example. Will I > get those from Folks as well? We don't currently pass along arbitrary fields. I've added bug #641211 comment #4 to address this (though it's honestly not a high priority for me). Specifically for the case of idle, I'm not sure it's worth adding an interface, but I've opened bug #663795 as a place for discussion.
(In reply to comment #2) > In the future though, you may wish to refer to AbstractFieldDetails symbols > when you're handling AFD-derived values in generic ways. > > Eg, > > if (FOLKS_IS_ABSTRACT_FIELD_DETAILS (fd)) > { > GType value_type = folks_abstract_field_details_get_value_type > (FOLKS_ABSTRACT_FIELD_DETAILS (fd)); > if (value_type == G_TYPE_STRING) > handle_afd_str (fd); > else if (value_type == FOLKS_TYPE_POSTAL_ADDRESS) > handle_afd_postal_address (fd); > } > > Though note that folks_abstract_field_details_get_value_type() hasn't been > merged to master yet. It's in my search branch, but I'll try to mainline it > sooner to simplify some of this code. See bug #663798
Guillaume, isn't this already done?
No, IIRC we still use the TP API to see those.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/empathy/issues/458.