1. 21 Jan, 2019 1 commit
    • Matthias Clasen's avatar
      settings: Make the keyfile backend parameterless · 26c8b29e
      Matthias Clasen authored
      Make it possible to instantiate a keyfile settings backend
      without specifying parameters, by turning the arguments to
      the new() function into construct-only properties. If no
      filename is specified, default to
  2. 29 May, 2017 1 commit
  3. 14 Mar, 2014 1 commit
    • Allison Karlitskaya's avatar
      gsettingsbackend: a minor simplification · 698970f1
      Allison Karlitskaya authored
      Change the order of the arguments on the (internal) keys_changed callback in
      This means that all functions in the table now fit the following signature:
        void (* f) (GObject             *target,
                    GSettingsBackend    *backend,
                    const gchar         *name_or_path,
                    gpointer             origin_tag,
                    const gchar * const *names);
      allowing the possibility of arguments ignored at the end.
      This allows us to simplify our dispatch-to-thread code in GSettingsBackend,
      making it a bit less generic.
      So far, this should be a straight refactor.
  4. 31 Jan, 2014 1 commit
  5. 28 Oct, 2013 1 commit
    • Allison Karlitskaya's avatar
      GSettingsBackend: add read_user_value() API · 84a6e651
      Allison Karlitskaya authored
      This will get the 'user' value from the database (ie: the one that the user has
      control over).
      Provide a default implementation that chains to ->read().  That will work for
      all of our internal backends which don't have a concept of layering or
      The delayed backend implments "user value" by returning anything that's
      in the changeset (incuding an explicit NULL) or chaining up otherwise.
      We will use this for g_settings_get_user_value().
  6. 18 Jan, 2013 1 commit
  7. 12 Apr, 2012 1 commit
  8. 02 Jan, 2012 1 commit
  9. 05 Jan, 2011 1 commit
  10. 03 Oct, 2010 1 commit
    • Allison Karlitskaya's avatar
      Bug 623400 - acquire context before dispatching · 0bd50b39
      Allison Karlitskaya authored
      For GSettings.
      Use the functionality introduced in the last commit to simplify our
      notify dispatching and increase the safety of doing so (by ensuring that
      the context is acquired in the current thread for the duration of the
      This closes bugs #623400 and #629849.
  11. 09 Sep, 2010 1 commit
  12. 22 Jul, 2010 1 commit
  13. 17 Jun, 2010 1 commit
  14. 11 Jun, 2010 1 commit
  15. 04 Jun, 2010 1 commit
  16. 17 May, 2010 3 commits
    • Allison Karlitskaya's avatar
      improve thread safety in GDelayedSettingsBackend · 799e0242
      Allison Karlitskaya authored
        - hold a lock while accessing the tree of delayed values
        - use weak reference counts with the owner object to avoid doing
          g_object_notify on a dead object
        - dispatch the "has-unapplied" notify to the proper main context
    • Allison Karlitskaya's avatar
      GSettingsBackend: make signal dispatch threadsafe · 61219e26
      Allison Karlitskaya authored
      This commit fixes up a few race conditions in the GSettingsBackend, mostly with
      respect to change notifications occuring at the same time as the last reference
      count on a GSettings is dropped.  With GDBus feeding us our incoming signals in
      a separate thread, this is something that could easily happen.
    • Allison Karlitskaya's avatar
      GSettings: support emitting signals in threads · 984258c6
      Allison Karlitskaya authored
      The thread-default context that was in effect at the time that the
      GSettings was created will be used for emitting signals on that
  17. 28 Apr, 2010 1 commit
  18. 16 Apr, 2010 1 commit
  19. 15 Apr, 2010 2 commits