diff options
author | Matthew Barnes <mbarnes@redhat.com> | 2012-07-16 04:08:41 +0800 |
---|---|---|
committer | Matthew Barnes <mbarnes@redhat.com> | 2012-07-16 04:08:41 +0800 |
commit | fcca366ecce1ffddaf6a280e248456127def1b4d (patch) | |
tree | e37bb3f512f10f2084ef55bc9a55548676b4b643 /art | |
parent | a1d2eb47189ccc2109d3080505de4a0319d2f18c (diff) | |
download | gsoc2013-evolution-fcca366ecce1ffddaf6a280e248456127def1b4d.tar gsoc2013-evolution-fcca366ecce1ffddaf6a280e248456127def1b4d.tar.gz gsoc2013-evolution-fcca366ecce1ffddaf6a280e248456127def1b4d.tar.bz2 gsoc2013-evolution-fcca366ecce1ffddaf6a280e248456127def1b4d.tar.lz gsoc2013-evolution-fcca366ecce1ffddaf6a280e248456127def1b4d.tar.xz gsoc2013-evolution-fcca366ecce1ffddaf6a280e248456127def1b4d.tar.zst gsoc2013-evolution-fcca366ecce1ffddaf6a280e248456127def1b4d.zip |
mail_session_add_service(): Make display-name binding one-way.
We're leaking CamelService references when we remove a CamelService
from a CamelSession. I don't yet know where or how.
If we remove a CamelService without finalizing the corresponding ESource,
and then add a new CamelService with the same UID, the ESource will have
a bidirectional "display-name" binding to multiple CamelService instances.
This creates an endless cascade of "notify" signals as soon as any of the
bound "display-name" properties change.
Until I can fix the leaking CamelService references, make the binding
one-way: ESource -> CamelService. This means the ESource's display name
is authoritative, and camel_service_set_display_name() MUST NOT be called
explicitly or else it will become out-of-sync with the ESource.
Diffstat (limited to 'art')
0 files changed, 0 insertions, 0 deletions