1. 13 Jul, 2012 1 commit
  2. 07 Jul, 2012 1 commit
  3. 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.
      e069bbe5
  4. 25 Jun, 2012 1 commit
  5. 23 Jun, 2012 1 commit
  6. 26 Mar, 2012 1 commit
  7. 19 Mar, 2012 1 commit
  8. 06 Jan, 2012 1 commit
  9. 25 Dec, 2011 1 commit
  10. 21 Dec, 2011 1 commit
    • Philip Withnall's avatar
      eds: Ignore empty values when creating AbstractFieldDetails instances · dd743bdc
      Philip Withnall authored
      We don't want to be passing around (e.g.) empty strings as e-mail addresses,
      or we'll cause bugs like bgo#666540.
      
      This modifies the EDS backend to check E.VCardAttribute.get_value() is not
      null or the empty string whenever it's called, and skip the attribute as
      appropriate.
      
      Helps: bgo#666540
      dd743bdc
  11. 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
      anyway.
      
      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
      2247cdd5
  12. 25 Nov, 2011 1 commit
  13. 10 Nov, 2011 1 commit
  14. 27 Oct, 2011 1 commit
  15. 25 Oct, 2011 1 commit
  16. 24 Oct, 2011 2 commits
  17. 11 Oct, 2011 2 commits
  18. 18 Sep, 2011 2 commits
  19. 17 Sep, 2011 2 commits
  20. 14 Sep, 2011 1 commit
  21. 13 Sep, 2011 1 commit
  22. 09 Sep, 2011 1 commit
    • Alexander Larsson's avatar
      e-d-s: Make sure consecutive property changes work · 00c12b1d
      Alexander Larsson authored
      Don't send any notification due to property changes until we've
      done updating an entire persona, otherwise code that listens to
      such notifies will see the persona in an intermediate state, whic
      can cause problems. For instance, if such a callback tries to
      change a property it might not recieve change notification for it.
      00c12b1d
  23. 08 Sep, 2011 1 commit
  24. 07 Sep, 2011 3 commits
  25. 06 Sep, 2011 1 commit
  26. 05 Sep, 2011 1 commit
  27. 04 Sep, 2011 1 commit
  28. 03 Sep, 2011 2 commits
  29. 02 Sep, 2011 5 commits