After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 651776 - Doesn't check SupportedLocationFeatures for Can_Set
Doesn't check SupportedLocationFeatures for Can_Set
Status: RESOLVED OBSOLETE
Product: empathy
Classification: Core
Component: Geolocation
3.1.x
Other Linux
: Normal normal
: ---
Assigned To: empathy-maint
empathy-maint
Depends on:
Blocks:
 
 
Reported: 2011-06-03 11:49 UTC by Will Thompson
Modified: 2018-05-22 14:49 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Will Thompson 2011-06-03 11:49:36 UTC
Today for some reason Empathy decided it had nothing better to do than call SetLocation on all of my accounts every 5 seconds. I couldn't see why—it stopped happening before I could get much useful information. But I noticed that it doesn't check the connection's SupportedLocationFeatures at any point: it just blindly calls SetLocation().

When I looked at EmpathyLocationManager I kind of boggled because it calls tp_account_manager_prepare_async() every time it wants to update the published location, even though tp_account_manager_prepare_async() is called in _init(). I can't see why it would do this. It doesn't, however, ensure the connection objects are prepared in any way. (Does TpAccountManager ensure that at least CONNECTION_FEATURE_CORE is prepared? I can never remember.)

I guess we could grow TP_CONNECTION_FEATURE_LOCATION which would grab all the properties and monitor them for changes … heh, LocationAccessControl is rw but doesn't have change notification.
Comment 1 Guillaume Desmottes 2011-06-07 13:59:40 UTC
(In reply to comment #0)
> When I looked at EmpathyLocationManager I kind of boggled because it calls
> tp_account_manager_prepare_async() every time it wants to update the published
> location, even though tp_account_manager_prepare_async() is called in _init().
> I can't see why it would do this. 

To 'simplify' the code so it doesn't have to check if the feature is already prepared maybe? But yeah, we should just go ahead and assume it has been I think.

> It doesn't, however, ensure the connection
> objects are prepared in any way. (Does TpAccountManager ensure that at least
> CONNECTION_FEATURE_CORE is prepared? I can never remember.)
> 
> I guess we could grow TP_CONNECTION_FEATURE_LOCATION which would grab all the
> properties and monitor them for changes … heh, LocationAccessControl is rw but
> doesn't have change notification.

That's the way to go, I opened https://bugs.freedesktop.org/show_bug.cgi?id=38036 about tp-glib API.
https://bugs.freedesktop.org/show_bug.cgi?id=27752 is about the lake of change signal.
Comment 2 GNOME Infrastructure Team 2018-05-22 14:49:58 UTC
-- 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/386.