aboutsummaryrefslogtreecommitdiffstats
path: root/libemail-utils
diff options
context:
space:
mode:
authorMatthew Barnes <mbarnes@redhat.com>2012-07-16 04:08:41 +0800
committerMatthew Barnes <mbarnes@redhat.com>2012-07-16 04:08:41 +0800
commitfcca366ecce1ffddaf6a280e248456127def1b4d (patch)
treee37bb3f512f10f2084ef55bc9a55548676b4b643 /libemail-utils
parenta1d2eb47189ccc2109d3080505de4a0319d2f18c (diff)
downloadgsoc2013-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 'libemail-utils')
0 files changed, 0 insertions, 0 deletions