Indicator Date and Time

Merge lp://qastaging/~ted/indicator-datetime/address-provider-change into lp://qastaging/indicator-datetime/12.10

  1. address-provider-change
  2. Merge into trunk.12.10
Proposed by Ted Gould
Status: Merged
Approved by: Charles Kerr
Approved revision: 184
Merged at revision: 184
Proposed branch: lp://qastaging/~ted/indicator-datetime/address-provider-change
Merge into: lp://qastaging/indicator-datetime/12.10
Diff against target: 56 lines (+0/-25)
1 file modified
src/datetime-service.c (+0/-25)
To merge this branch: bzr merge lp://qastaging/~ted/indicator-datetime/address-provider-change
Reviewer Review Type Date Requested Status
Charles Kerr (community) Approve
jenkins (community) continuous-integration Approve
Review via email: mp+124068@code.qastaging.launchpad.net

Commit message

No longer watch if the address provider changes

Description of the change

Address provider changing is really more informative than something we should worry about. It can happen often, but all we care about here is if the address changes, and we already watch that. We definitely should not be clearing our address provider pointers if it changes as we're not actually looking at the provider, but the master provider. This is probably what has caused the datetime detection to be less reliable than we would have liked.

To post a comment you must log in.
Revision history for this message
jenkins (martin-mrazik+qa) wrote :

PASSED: Continuous integration, rev:184
http://jenkins.qa.ubuntu.com/job/indicator-datetime-ci/5/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/indicator-datetime-ci/./label=quantal/5/console

review: Approve (continuous-integration)
Revision history for this message
Charles Kerr (charlesk) wrote :

Ted, could you expand on that last comment? I don't see how this could make the detection less reliable.

Regardless of that point, though, I agree with this patch on the basis of removing unnecessary code. Rebuilding our geoclue-based menuitems on address-provider-changed is extra churn when we're already updating on GeoAddress' address-changed signal.

review: Approve
Revision history for this message
Ted Gould (ted) wrote :

On Thu, 2012-09-13 at 06:42 +0000, Charles Kerr wrote:
> Ted, could you expand on that last comment? I don't see how this could
> make the detection less reliable.

Basically we get two signals from the master. The first is to tell us
the value that it knows we have changes, the second is saying how it got
it changed. This removes the listener for the "how it got it" signal,
because, frankly we don't care. But, where the actual error is that we
were responding to the how it got it signal by assuming everything
should be redone, when in reality, they're entirely unrelated and
GeoClue would return errors about recreating things.

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
The diff is not available at this time. You can reload the page or download it.

Subscribers

People subscribed via source and target branches