GNOME Bugzilla – Bug 660383
Backends should listen for changes in refresh interval
Last modified: 2012-08-22 17:25:26 UTC
(This could instead be an evo bug but it's not clear to me) 1. Add Google contacts address book (make sure "Copy contacts" is unchecked) 2. Set refresh period to 1 minute to make the remaining steps quicker 3. Delete a contact from Google contacts 4. wait for e-d-s to refresh The contact should be removed locally by now, but it isn't. However, it's stale, since you'll hit a ContactNotFound error if you try to delete it from Evo at this point. I deleted another contact directly from Evo and it was removed as expected in Google contacts.
I noticed this behavior as well. After turning mine down from 100 minutes to 1 minutes, I still experienced delay. In my case I did even a few more things to stimulate the refresh: a) Created a contact "A" in Evolution (shows up immediately in google contacts) b) Created a second contact "AA" in Google contacts (immediately after the last step) c) Deleted the first contact "A" in Google contacts d) Changed refresh, moved to calendar back to contacts, applied search e) Waited nearly 10 minutes (with refresh set to 1 minute) f) Repeated d g) Modified another contact h) reloaded evolution I only see "A" in evolution still but should be only seeing "AA". An evolution --force-shutdown was the only thing I seemed to be able to do within 15 minutes to get the expected "A" disappearing and "AA" appearing.
Thanks for a bug report. I tried to reproduce this and it works for me as expected. Except of one thing, the refresh interval change is propagated to the backend only after the factory restart, not immediately when the change is done, thus if you change the interval to 1 minute then you may close the addressbook factory as well. With that the refresh is done each minute for me and the UI is updated as expected. Could you retest, please? In case it'll not work for you, please run the factory with exported GOOGLE_BACKEND_DEBUG=1, then the factory's console will be full of debugging prints for google addressbook.
I confirmed that after changing to a one minute refresh interval, and restarting the backend factory, the evolution interface now refreshes the changes in the expected manner when following my steps above. In my case, I have been restoring backups to return me to a consistent state, which include the default 100 minute interval, so I never left it at 1 minute long enough (across factory restart / reboot) to see this behavior.
The bug appears to be that the refresh setting does not impact the current session / factory instance.
Thanks for the update. I'm changing summary accordingly and confirming the bug.
Created attachment 198929 [details] [review] eds patch for evolution-data-server; This should work, but it doesn't, because the factory doesn't listen for changes on ESource-s. I guess this will be fixed with the account-management changes, because the same functionality was provided for calendar backends too, but it was dropped by Matthew only recently. Once it's fixed the patch can be properly tested and committed to sources.
With this patch and my current 3.2.0, I had to purge the last five lines to make it apply cleanly. But then it just failed the build so unable to test. Is this patch suitable for 3.2.0... maybe I can take the id and find the equivalent in 3.2.0 source tree.
if there is a 3.2.0 patch I can test against my current ubuntu source
it is the first hunk in e-book-backend-google.c hunk I can't seem to patch manually without errors or warnings.
It'll not work with 3.2.x, same as it doesn't work with master at the moment too, because the evolution-addressbook-factory doesn't listen for changes being done on ESource-s. I hope this will be working fine when account-management changes will reach master branch.
(In reply to comment #10) > It'll not work with 3.2.x, same as it doesn't work with master at the moment > too, because the evolution-addressbook-factory doesn't listen for changes being > done on ESource-s. I hope this will be working fine when account-management > changes will reach master branch. An ESource's refresh interval will be a GObject property and will emit "notify" signals when changed as you'd expect, but I haven't written any new code to make backends react to changes if they weren't already listening. http://mbarnes.fedorapeople.org/account-mgmt/docs/libedataserver/ESourceRefresh.html I'll see if I can come up with some helper functions for this extension that register a timeout GSource for you and keep it updated if the interval changes. Then backends could use that instead of g_timeout_add().
It's not it. I was aiming into removal of ESourceList in the factory itself, which took care of listening on updates, thus the ESource::changed signal was emitted properly when the ESource definition changed. I do not expect you adding such "listen for ESource::changed" signal into each backend, I'm rather expecting your account-management changes will provide same functionality like if ESourceList being involved now. If it does, then good.
*** Bug 662786 has been marked as a duplicate of this bug. ***
Created attachment 222171 [details] [review] eds patch ][ for evolution-data-server; Matthew's changes make code simpler :)
Crated commit b6ca76f in eds master (3.5.91+)