In order to properly fix https://bugzilla.gnome.org/show_bug.cgi?id=651776 we should add Location support to TpConnection.
http://cgit.collabora.com/git/user/cassidy/telepathy-glib/log/?h=location-38036 I only added API on the features as: - LocationAccessControl doesn't have a signal so we wouldn't be able to update the property - I'm not sure how we want to represent location; maybe we want something better than a TpAsv? - That's all I need to fix the Empathy bug :) But that shouldn't block review and merge of this branch.
(In reply to comment #1) > - I'm not sure how we want to represent location; maybe we want something > better than a TpAsv? It'd be good to follow tp-qt4's lead and return an opaque thing (GObject, or possibly boxed struct), with convenience accessors for the well-known keys (tp_location_get_latitude() etc.) plus a way to peek at the actual contents. Migrating to GDBus or changing the D-Bus API would break the API of the latter but not the former. Complications for the convenience API: * everything needs to be "nullable" ("not known" is always a possible answer) * some properties only make sense in groups - e.g. perhaps have: /** * lat: (out): latitude in degrees north (negative if south of the Equator), * undefined if %FALSE is returned * lat: (out): longitude in degrees east (negative if west of Greenwich), * undefined if %FALSE is returned * Returns: %TRUE if both @lat and @long are meaningful */ gboolean tp_location_get_coordinates (TpLocation *, gdouble *lat, gdouble *long);
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org'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.freedesktop.org/telepathy/telepathy-glib/issues/67.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.