| Summary: | ContactInfoChanged is emitted 2 times in response to RefreshContactInfo | ||
|---|---|---|---|
| Product: | Telepathy | Reporter: | Xavier Claessens <xclaesse> |
| Component: | gabble | Assignee: | Telepathy bugs list <telepathy-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | Telepathy bugs list <telepathy-bugs> |
| Severity: | normal | ||
| Priority: | medium | Keywords: | patch |
| Version: | git master | ||
| Hardware: | Other | ||
| OS: | All | ||
| URL: | http://git.collabora.co.uk/?p=user/jonny/telepathy-gabble.git;a=shortlog;h=refs/heads/ch-ch-ch-changed | ||
| Whiteboard: | review+ish | ||
| i915 platform: | i915 features: | ||
|
Description
Xavier Claessens
2010-05-27 17:30:10 UTC
What do you think of this then? I never worked on that code, but it seems to make sense :) + # ContactInfoChanged should not be signalled again
+ forbidden = [EventPattern('dbus-signal', signal='ContactInfoChanged')]
+ q.forbid_events(forbidden)
+
# Refresh the contact info again; gabble should contact the server again
call_async(q, conn.ContactInfo, 'RefreshContactInfo', [handle])
event = q.expect('stream-iq', to='bob@foo.com', query_ns='vcard-temp',
query_name='vCard')
+ sync_dbus(bus, q, conn)
+
+ q.unforbid_events(forbidden)
I think you can put the sync_dbus() call and unforbid thing above the call_async, no?
But it basically looks fine.
(In reply to comment #3) > I think you can put the sync_dbus() call and unforbid thing above the > call_async, no? I deliberately wanted the unforbid_events to be quite late the signal never should have been fired again. I'm going to merge it as is. Thanks! |
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.