1. 09 Aug, 2012 2 commits
    • Philip Withnall's avatar
      docs: Various small fixes and expansions of documentation · e7b96a7b
      Philip Withnall authored
       • Various links fixed to point to class documentation rather than its
         constructor documentation (this is a quirk of Valadoc; if using
         “{@link ClassName}” inside a method of ClassName, the link will point to
         ClassName’s constructor because symbols are resolved relatively and the
         class’ constructor is called “ClassName”).
       • Various bits of documentation expanded (mostly trivially) to shut gtk-doc
         up about missing long descriptions.
       • Some Vala code attributes moved around so the documentation comments are
         correctly associated with the code. (This shouldn’t change the behaviour
         of the attributes themselves.)
       • Some trivial constructors added to classes in order to give them
       • Constructor for Utils added and deprecated immediately. Utils should
         become a nested namespace on the next API break, since it will only ever
         contain static methods, and thus doesn’t need to be instantiable (which
         folks will make it at the moment).
    • Erick Pérez Castellanos's avatar
      telepathy backend fixed to match last vala release. · 887aab26
      Erick Pérez Castellanos authored
      Vala change:
      1. Warn when accessing static members with an instance reference.
      2. Deprecate implicit .begin for async methods.
      Bug: https://bugzilla.gnome.org/show_bug.cgi?id=681420
  2. 24 Jul, 2012 1 commit
  3. 19 Jul, 2012 3 commits
    • 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
  4. 13 Jul, 2012 1 commit
  5. 11 Jul, 2012 1 commit
  6. 06 Jul, 2012 1 commit
    • Jeremy Whiting's avatar
      Port folks to libgee 0.8. · e069bbe5
      Jeremy Whiting authored
      Added hash_static and equal_static to AbstractFieldDetails.
      Use AbstractFieldDetails hash_static and equal_static where needed.
  7. 18 Jun, 2012 1 commit
  8. 13 Jun, 2012 2 commits
  9. 12 Jun, 2012 1 commit
  10. 28 May, 2012 1 commit
  11. 30 Apr, 2012 2 commits
  12. 25 Apr, 2012 1 commit
  13. 17 Apr, 2012 4 commits
  14. 10 Apr, 2012 3 commits
  15. 09 Apr, 2012 1 commit
  16. 28 Mar, 2012 1 commit
  17. 26 Mar, 2012 2 commits
  18. 19 Mar, 2012 1 commit
  19. 27 Jan, 2012 1 commit
  20. 13 Dec, 2011 2 commits
  21. 10 Dec, 2011 1 commit
    • Philip Withnall's avatar
      Bug 665692 — Use constructors correctly · 2247cdd5
      Philip Withnall authored
      In order to allow libfolks to be used from introspected languages (such as
      Python) properly, we need to correctly use the GObject construction process,
      rather than generating code which does all object initialisation inside
      a *_new() function. This involves moving lots of code into construct{} blocks.
      There are some complications; mostly the need for various private variables to
      now be exposed as construct-only properties. Most of them should've been
      Other complications arose from the fact that moving code to a construct{}
      block can subtly change the execution order of the code if the Object() call
      lists properties which are non-construct properties (e.g. the “alias” property
      of a Persona). The setters for these properties will now be called _after_ the
      construct{} code, whereas previously they would've been called beforehand.
      This rears its head in Tpf.Persona, but hopefully nowhere else.
      Closes: bgo#665692
  22. 25 Nov, 2011 1 commit
  23. 18 Oct, 2011 1 commit
  24. 17 Oct, 2011 1 commit
  25. 11 Oct, 2011 4 commits