1. 20 Oct, 2014 2 commits
  2. 28 Jul, 2014 1 commit
  3. 08 Jul, 2014 2 commits
  4. 25 Jun, 2014 1 commit
    • Milan Crha's avatar
      store_info_insert_folder_info: Use g_hash_table_replace() to avoid use-after-free · 26e35964
      Milan Crha authored
      The previously used g_hash_table_insert() replaces only value for keys
      which are already included in the hash table, but as the key is owned
      by the value and freed together with the value, then here should
      be used g_hash_table_replace(), which replaces both key and value,
      thus avoids the use-after-free on the hash table's key.
      26e35964
  5. 10 Jun, 2014 1 commit
  6. 09 Jun, 2014 1 commit
  7. 05 Jun, 2014 1 commit
    • Milan Crha's avatar
      Ignore false GSettings key change notifications · 6e9e7b06
      Milan Crha authored
      Similar to GObject::notify, the GSettings::changed can be emitted
      even if a key didn't change. It's up to the user (aka evolution)
      to test for real changes, thus let's do it. It may have certain
      performance positive impact too.
      6e9e7b06
  8. 04 Jun, 2014 1 commit
    • Milan Crha's avatar
      Ignore false GObject property change notifications · 2f3fbdd6
      Milan Crha authored
      This is related to bug 698275, which did not cover all cases.
      The problem here is that the dconf can in certain situation claim
      that everything changed (path "/" changed), which GSettingsBinding
      propagates to a GObject property unconditionally and GObject's
      property setter (g_object_set_property()) also notifies about
      the property change unconditionally, despite the real descendant
      property setter properly checks for the value change. After all
      these false notifications a callback on "notify" signal is called
      and possibly an expensive operation is run.
      
      Checking whether the value really changed helps in performance, for
      which were added new e-util functions:
         e_signal_connect_notify()
         e_signal_connect_notify_after()
         e_signal_connect_notify_swapped()
         e_signal_connect_notify_object()
      which have the same prototype as their GLib counterparts, but they allow
      only "notify::..." signals and they test whether the value really changed
      before they call the registered callback.
      2f3fbdd6
  9. 25 Mar, 2014 1 commit
  10. 26 Feb, 2014 1 commit
    • Tarnyko's avatar
      Replace 'interface' with 'iface' in the code · 5c60d570
      Tarnyko authored
      Win32 headers have a #define for 'interface', which breaks the build
      when this word is used in the code, thus replace it to 'iface',
      the same way as GLib or GTK+ code use to have it. (See bug #722068.)
      5c60d570
  11. 24 Feb, 2014 1 commit
  12. 23 Feb, 2014 1 commit
  13. 21 Feb, 2014 1 commit
  14. 20 Feb, 2014 1 commit
  15. 10 Feb, 2014 2 commits
  16. 03 Feb, 2014 1 commit
  17. 23 Jan, 2014 1 commit
  18. 17 Jan, 2014 1 commit
  19. 07 Jan, 2014 1 commit
  20. 10 Dec, 2013 1 commit
  21. 07 Dec, 2013 1 commit
  22. 30 Nov, 2013 3 commits
  23. 29 Nov, 2013 1 commit
  24. 27 Nov, 2013 5 commits
  25. 26 Nov, 2013 4 commits
  26. 24 Nov, 2013 1 commit
  27. 15 Nov, 2013 1 commit
    • Milan Crha's avatar
      Fix/mute issues found by Coverity scan · 570c6374
      Milan Crha authored
      This makes the code free of Coverity scan issues.
      It is sometimes quite pedantic and expects/suggests some
      coding habits, thus certain changes may look weird, but for a good
      thing, I hope. The code is also tagged with Coverity scan
      suppressions, to keep the code as is and hide the warning too.
      Also note that Coverity treats g_return_if_fail(), g_assert() and
      similar macros as unreliable, and it's true these can be disabled
      during the compile time, thus it brings in other set of 'weird'
      changes.
      570c6374
  28. 13 Nov, 2013 1 commit