1. 02 Feb, 2018 1 commit
  2. 05 Jan, 2018 1 commit
  3. 07 Jul, 2017 1 commit
  4. 29 May, 2017 1 commit
  5. 12 Oct, 2016 1 commit
  6. 25 Aug, 2016 1 commit
  7. 03 Mar, 2016 1 commit
  8. 01 Sep, 2015 1 commit
  9. 07 Aug, 2015 1 commit
  10. 05 Jun, 2015 1 commit
    • Allison Karlitskaya's avatar
      gsettings tool: use schema for listing keys · bb8eea61
      Allison Karlitskaya authored
      Use the newly added g_settings_schema_list_keys() API instead of
      g_settings_list_keys() in order to list keys.
      
      Doing this allows the 'list-keys' command to work without creating a
      GSettings object, which is more efficient.  It also means that we don't
      have to provide a (meaningless and ignored) path when listing keys on
      relocatable schemas.
      
      While we're at it, update the 'range' command not to require creation of
      a GSettings object, in a similar way.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=740308
      bb8eea61
  11. 19 Nov, 2014 1 commit
    • Allison Karlitskaya's avatar
      GSettings: delay backend subscription · 8ff5668a
      Allison Karlitskaya authored
      GSettings objects begin watching for changes as soon as they are created
      in order that they can emit the "changed" signal.
      
      In the case of dconf, if we want to be able to emit the changed signal,
      we need to go on the bus and add some match rules.  This requires
      creating the dconf helper thread and also requires initialising GDBus
      (which creates another thread).
      
      Some users of GSettings are never interested in the "changed" signal.
      One of these users is the glib-networking code that gets run every time
      a new network connection is created.
      
      Some users are reporting that they are annoyed that simply establishing
      a network connection would spawn two extra threads and create a D-Bus
      connection.
      
      In order to avoid doing unnecessary work for these simple uses, delay
      the subscription until we know that we will actually need to do it.
      
      We do this in a simple way, using a simple argument: in order for the
      user to care that a value changed then they must have:
      
       1) watched for a change signal; and then
       2) actually read a value
      
      If the user didn't actually read a value then they cannot possibly be
      interested in if the value changed or not (since they never knew the old
      value to begin with and therefore would be unable to observe that it
      ever changed, since they have nothing to compare the new value with).
      
      This really is a behaviour change, however, and it does impact at least
      one user: the 'monitor' functionality of the GSettings commandline tool,
      which is interested in reporting changes without ever having known the
      original values.  We add a workaround to the commandline tool in order
      to ensure that it continues to function properly.
      
      It's also possible to argue that it is completely valid to have read a
      value and _then_ established a change signal connection under the
      (correct) assumption that it would not have been possible to miss a
      change signal by virtue of not having returned to the mainloop.
      Although this argument is true, this pattern is extremely non-idiomatic,
      and the problem is easily avoided by doing things in the usual order.
      
      We never really talked about change notification in the overview
      documentation for GSettings, so it seems like now is a good time to add
      some discussion, including the new rules for when one can expect change
      signals to be emitted.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=733791
      8ff5668a
  12. 31 Jan, 2014 1 commit
  13. 22 Dec, 2013 1 commit
  14. 27 Nov, 2013 2 commits
  15. 28 Oct, 2013 2 commits
  16. 24 Oct, 2013 1 commit
  17. 19 Jul, 2013 1 commit
  18. 04 Apr, 2013 1 commit
  19. 09 Mar, 2013 1 commit
  20. 15 Nov, 2012 1 commit
  21. 16 Oct, 2012 1 commit
  22. 28 Aug, 2012 1 commit
  23. 02 Feb, 2012 1 commit
  24. 20 Jan, 2012 1 commit
    • Matthias Clasen's avatar
      Fix a refcounting error · 8852d4e9
      Matthias Clasen authored
      'new' is created floating, therefore it is consumed by
      g_settings_set, and unreffing it after that call is not right.
      8852d4e9
  25. 19 Dec, 2011 1 commit
  26. 07 Jun, 2011 1 commit
  27. 23 May, 2011 1 commit
  28. 18 May, 2011 1 commit
  29. 17 May, 2011 1 commit
  30. 12 Apr, 2011 2 commits
  31. 09 Apr, 2011 1 commit
  32. 23 Feb, 2011 1 commit
    • Matthias Clasen's avatar
      Allow to list keys in all schemas · 766d7072
      Matthias Clasen authored
      Make the schema argument to gsettings list-recursively optional.
      This allows to search for not exactly known keys by going
      
      gsettings list-recursively | grep 'font'
      766d7072
  33. 12 Feb, 2011 1 commit
  34. 21 Jan, 2011 1 commit
  35. 12 Dec, 2010 1 commit
  36. 01 Nov, 2010 1 commit
  37. 30 Oct, 2010 1 commit