1. 23 Jul, 2012 4 commits
    • Travis Reitter's avatar
      Prevent extra "concurrent" PersonaStore.prepare() calls from one thread. · d94b174d
      Travis Reitter authored
      The lock() calls which were in place only prevent concurrent calls from
      different threads; however, the critical section could still be reached
      from two async calls in the same thread a la:
      backend.prepare.begin ((s,r) => {...});
      backend.prepare.begin ((s,r) => {...});
      The bodies of the handlers would not literally execute concurrently, but
      would be interleaved if each were sufficiently long. Our fix simply
      ignores any calls which happen while one is still working.
      (yield backend.prepare(); yield backend.prepare(); was already safe, of
      Helps: bgo#652637 - Don't hold locks across async calls
    • Travis Reitter's avatar
      Add test cases for mutexing for async calls from the same thread. · 1492a80a
      Travis Reitter authored
      The standard Vala lock() call is a recursive lock, so it only prevents
      concurrent access between different threads. But we rarely run in
      distinct threads, so this test uses a more-complete solution that we can
      depend upon (since the test will fail if its assumptions ever change in
      Helps: bgo#652637 - Don't hold locks across async calls
    • Travis Reitter's avatar
      Fix Tracker structure locking for user-initiated Persona adds. · 67f8e41b
      Travis Reitter authored
      Helps: bgo#652637 - Don't hold locks across async calls
    • Kjartan Maraas's avatar
      Updated Norwegian bokmål translation · 35e6e8f5
      Kjartan Maraas authored
  2. 22 Jul, 2012 2 commits
  3. 19 Jul, 2012 5 commits
    • Ihar Hrachyshka's avatar
      Added Belarusian translation. · 95496d95
      Ihar Hrachyshka authored
    • Philip Withnall's avatar
      core: Fix documentation on GroupDetails.groups · 62f0cce5
      Philip Withnall authored
      It was out of date and didn’t match the data type of GroupDetails.groups
      any more.
      See: https://bugzilla.gnome.org/show_bug.cgi?id=679743
    • Philip Withnall's avatar
      telepathy: Preserve Tpf.Persona avatars from the cache for online contacts · c2338c65
      Philip Withnall authored
      This is a fairly hacky way of fixing the problem in bug #660128: maintaining
      a map of IIDs to avatar files for all personas in the Telepathy backend, and
      referring to it in case Telepathy doesn’t know the current avatar for a
      TpContact. This can happen if that contact is currently offline while we’re
      online, for example. This allows use of the avatars cached from last time
      contacts were online, even though those contacts are now offline.
      A more comprehensive fix, which I would have implemented if I hadn’t just got
      my degree classification and weren’t just heading out to celebrate, would
      involve rearchitecting the caching of the Telepathy backend so that the
      Tpf.Personas weren’t destroyed and re-created whenever the backend went
      offline/online; instead, they would have their properties updated from the
      cache/online contact list. This would eliminate spurious personas-changed
      signals, unify the code implementing the different properties (currently it’s
      split between the properties and separate implementations in
      Tpf.Persona.from_cache()), and allow property values to persist from offline
      to online without the need for hacks like this.
      Closes: https://bugzilla.gnome.org/show_bug.cgi?id=660128
    • Philip Withnall's avatar
      telepathy: Allow for updated Tpf.Personas properties to update the cache · 36ecd01a
      Philip Withnall authored
      Currently, the cache is only written when going offline, which means that any
      properties of Tpf.Personas which are updated at runtime aren’t written to the
      cache unless the client explicitly goes offline before being closed. This
      doesn’t often happen, meaning the property updates are lost and the cache
      becomes stale.
      This commit keeps track of the clean/dirty state of the cache and writes it
      out when PersonaStore.flush() is called. It also adds a new method,
      IndividualAggregator.unprepare(), which ensures all the persona stores handled
      by the aggregator are flushed. Clients should call this method before closing
      their main loop.
      (Calling flush() in the finalise function of the PersonaStore doesn’t work
      because Tpf.PersonaStores are often never finalised due to the implementation
      of Tpf.PersonaStore.dup_for_account(). Furthermore, calling flush() in the
      finalise function of the IndividualAggregator doesn’t work because the client
      will typically quit the main loop immediately afterwards, which will cancel
      the asynchronous flush call.)
      New API:
       • IndividualAggregator.unprepare()
      Helps: https://bugzilla.gnome.org/show_bug.cgi?id=660128
    • Philip Withnall's avatar
      core: Don’t keep references to PersonaStores in each Individual · 6f743fdc
      Philip Withnall authored
      Pointless and it makes debugging reference counting bugs a real pain.
  4. 18 Jul, 2012 1 commit
  5. 17 Jul, 2012 2 commits
  6. 16 Jul, 2012 8 commits
  7. 14 Jul, 2012 2 commits
  8. 13 Jul, 2012 5 commits
  9. 12 Jul, 2012 1 commit
  10. 11 Jul, 2012 1 commit
  11. 10 Jul, 2012 1 commit
  12. 09 Jul, 2012 1 commit
  13. 08 Jul, 2012 1 commit
  14. 07 Jul, 2012 6 commits