1. 10 Jun, 2014 6 commits
  2. 09 Jun, 2014 2 commits
  3. 06 Jun, 2014 3 commits
  4. 05 Jun, 2014 3 commits
    • Milan Crha's avatar
    • 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.
    • Milan Crha's avatar
      Properly disconnect signal handlers added with e_signal_connect_notify*() · 2e71c861
      Milan Crha authored
      This is a follow-up for the previous commit, where e_signal_connect_notify*()
      functions had been added. Due to a different callback and user data being
      attached to the 'notify' signal, the g_signal_handlers_*() functions do not
      work properly, thus these e_signal_connect_notify*() functions need
      a different way for a signal handler disconnect.
      A side-change was done in e-settings-web-view-gtkhtml.c, checking for a real
      key change from GSettings.
  5. 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:
      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.
  6. 03 Jun, 2014 2 commits
  7. 02 Jun, 2014 2 commits
  8. 30 May, 2014 1 commit
  9. 29 May, 2014 3 commits
  10. 28 May, 2014 1 commit
  11. 27 May, 2014 2 commits
  12. 26 May, 2014 5 commits
  13. 23 May, 2014 3 commits
  14. 22 May, 2014 1 commit
  15. 20 May, 2014 3 commits
  16. 19 May, 2014 2 commits