1. 07 Jul, 2012 4 commits
  2. 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.
  3. 27 Jun, 2012 2 commits
  4. 22 Jun, 2012 1 commit
    • Philip Withnall's avatar
      core: Change default EDS PersonaStore ID to ‘system-address-book’ · 392ece02
      Philip Withnall authored
      The new version of EDS uses that instead of ‘system’. This shouldn’t pose
      upgrade problems (e.g. if a user has ‘system’ stored in GSettings), since in
      that case the ‘system’ persona store wouldn’t be found, and the fallback
      would be to use the persona store marked as the system-set default — which
      is the ‘system-address-book’ persona store, as required.
  5. 25 Apr, 2012 1 commit
  6. 23 Apr, 2012 1 commit
  7. 17 Apr, 2012 1 commit
  8. 16 Apr, 2012 1 commit
  9. 28 Mar, 2012 1 commit
    • Xavier Claessens's avatar
      Increase quiescent timeout to 30s · ada8261b
      Xavier Claessens authored
      5s is too optimistical, it can easily take longer when printing debug
      messages on terminal (unit test failing because of this) or even in real
      world usage if system is a bit on load.
  10. 19 Mar, 2012 1 commit
    • Philip Withnall's avatar
      core: Improve quiescence timeout · 910d6c29
      Philip Withnall authored
      Ensure that we start the timeout in the case that all backends are marked
      as quiescent (meaning that they've added all their persona stores), but none
      of the persona stores are.
  11. 08 Mar, 2012 1 commit
  12. 17 Feb, 2012 1 commit
    • Travis Reitter's avatar
      Cut invalid overly-specific type cast · c0003918
      Travis Reitter authored
      The Vala compiler now correctly warns that typeof(Foo<Bar>) is invalid,
      so this stops pretending we can be that specific.
      (The generated C code can't make a GValue as specific as the above Vala
      code fragment suggests; historically, the compiler would let you get
      away with this, likely with the false assumption that the generic type
      would ever be considered again.)
  13. 09 Jan, 2012 1 commit
    • Philip Withnall's avatar
      Bug 667410 — A second aggregator instance only fetches a subset of contacts · d258c868
      Philip Withnall authored
      This was happening because the initial BackendStore was hanging around across
      multiple IndividualAggregator instances, keeping all the Backends,
      PersonaStores and Personas alive.
      The IndividualAggregator didn’t have code to deal with pre-prepared Backends
      and PersonaStores, meaning it never realised the Personas existed (because
      they weren’t announced via personas-changed signals), and thus never created
      Individuals out of them.
      This commit fixes the problem by having IndividualAggregator check for
      existing Backends, PersonaStores and Personas when prepare() is called.
      It also adds a test case to the folks test suite, based on the one written
      by Guillaume in bgo#667410.
      Closes: https://bugzilla.gnome.org/show_bug.cgi?id=667410
  14. 06 Jan, 2012 1 commit
    • Philip Withnall's avatar
      core: Nullability fixes · d3385bae
      Philip Withnall authored
      Almost all of these are just the necessary ‘(!)’ annotations to allow the
      nullability check to pass. There were few, if any, actual bugs found by the
      check (which either means folks is perfect, or Vala's nullability checking
      is imperfect).
      This brings us down from 296 nullability errors to just below 50.
      The work was done by compiling folks with valac’s
      --enable-experimental-non-null flag. We’re not ready to add the flag to
      VALAFLAGS permanently yet, since this commit depends on various annotation
      fixes in GLib (and similarly, the next one depends on several in EDS).
      However, the fixes themselves should be valid without the flag.
      This depends on (at least):
       • https://bugzilla.gnome.org/show_bug.cgi?id=666700https://bugzilla.gnome.org/show_bug.cgi?id=666699
  15. 28 Dec, 2011 1 commit
  16. 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
  17. 09 Dec, 2011 1 commit
    • Philip Withnall's avatar
      backends: Tidy up prepare() and unprepare() methods’ mutual exclusion · 58dba5a8
      Philip Withnall authored
      As discovered in bgo#665728, all our prepare() (and unprepare()) methods are
      currently vulnerable to being run multiple times concurrently from a single
      thread. Add a _pending_prepare flag to all of them to prevent this. It
      doesn't need to be locked, since it should only ever be accessed from a
      single thread (since only a single thread can get through the lock{}
      recursive mutex at once).
      Helps: bgo#665728
  18. 08 Dec, 2011 1 commit
  19. 28 Oct, 2011 2 commits
    • Travis Reitter's avatar
      Generate the same C code whether the eds backend is enabled or not. · b15f6e0e
      Travis Reitter authored
      Previously, the configure options used would alter the release tarball.
      This would cause problems for anyone building from the shipped C files
      (specifically, if they also disabled the eds backend, as the Debian
      packagers did).
      Closes: bgo#662274 - Failed to link personas: Can't link personas with
      no primary store.
    • Travis Reitter's avatar
      Warn if the primary store is not found. · 7e20483e
      Travis Reitter authored
      This includes steps for the user to fix the problem.
      Helps: bgo#662274 - Failed to link personas: Can't link personas with
      no primary store.
  20. 24 Oct, 2011 1 commit
  21. 27 Sep, 2011 1 commit
  22. 18 Sep, 2011 1 commit
  23. 16 Sep, 2011 3 commits
  24. 14 Sep, 2011 2 commits
  25. 12 Sep, 2011 1 commit
  26. 08 Sep, 2011 2 commits
  27. 07 Sep, 2011 5 commits
    • Philip Withnall's avatar
      Bug 656689 — Re-link personas on linkable properties being changed · cd1fd7f6
      Philip Withnall authored
      Listen for notifications of changes to the linkable properties of every
      persona in the IndividualAggregator. When we receive such a notification,
      relink that persona by artificially removing them from the aggregator and
      immediately re-adding them.
      Like many things in the IndividualAggregator, this is ugly — but it appears
      to work, and I can get my head around it.
      Closes: bgo#656689
    • Philip Withnall's avatar
      core: Fix individuals_changed_detailed mappings for unlinked individuals · 7b74199a
      Philip Withnall authored
      It turns out that we can do a post-processing phase on the mappings to be
      emitted by IndividualAggregator.individuals_changed_detailed and ensure that
      individuals who've been unlinked are represented by a mapping from themselves
      to the set of individuals replacing them, rather than a mapping from
      themselves to null, and null to the set of individuals replacing them.
      This probably isn't the most efficient way to fix the problem, but it works
      and I can just about understand it.
      Helps: bgo#656689, bgo#657282
    • Philip Withnall's avatar
      core: Be more thorough when removing individuals from the link map · 55abd838
      Philip Withnall authored
      Since the values of personas' linkable properties could've changed since we
      added them to the link map, we have to be more thorough when removing
      individuals from the map. We therefore now remove them by examining all the
      values in the map, and removing every mapping to the individual we're
      interested in.
      Helps: bgo#656689
    • Philip Withnall's avatar
      core: Add more debug output and validation to the IndividualAggregator · fa1fb9f4
      Philip Withnall authored
      Everyone loves debug output, and validating that we aren't leaving stale
      entries in the link map which will later cause whoever's looking into
      aggregator bugs to hide in a corner and cry.
      Helps: bgo#656689
    • Philip Withnall's avatar
      core: Ensure we always notify of new Individuals · 150b7579
      Philip Withnall authored
      In the following situation, it was possible for
      IndividualAggregator.individuals_changed_detailed to not emit a notification
      that an individual was added:
      If two personas were added by a given store in the same emission of
      PersonaStore.personas_changed, the IA would create an Individual, i1, from
      the first and add a mapping (null → i1) to the change set. It would then
      process the second, destroying the first individual and creating a new
      Individual, i2, (correctly) containing both personas. In doing so, it would
      remove the mapping (null → i1) from the change set, but would incorrectly
      not add a mapping (null → i2) in its place.
      This situation can be extended to others where a single new Individual is
      formed from multiple new personas coming from a single emission of
      Closes: bgo#657282 (again)