1. 28 Nov, 2014 1 commit
  2. 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
  3. 24 Jun, 2014 2 commits
  4. 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
      GSettingsListenerVTable.
      
      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.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=710367
      698970f1
  5. 09 Feb, 2014 1 commit
    • Matthias Clasen's avatar
      Docs: Drop entities, switch away from sgml mode · 35066ed6
      Matthias Clasen authored
      Since all element markup is now gone from the doc comments,
      we can turn off the gtk-doc sgml mode, which means that from
      now on, docbook markup is no longer allowed in doc comments.
      
      To make this possible, we have to replace all remaining
      entities in doc comments by their replacement text, & -> &
      and so on.
      35066ed6
  6. 08 Feb, 2014 1 commit
  7. 06 Feb, 2014 4 commits
  8. 02 Feb, 2014 1 commit
  9. 01 Feb, 2014 4 commits
  10. 31 Jan, 2014 1 commit
  11. 21 Jan, 2014 1 commit
  12. 08 Jan, 2014 1 commit
  13. 02 Jan, 2014 1 commit
  14. 09 Dec, 2013 1 commit
  15. 06 Dec, 2013 1 commit
  16. 09 Nov, 2013 1 commit
  17. 28 Oct, 2013 3 commits
  18. 24 Oct, 2013 1 commit
  19. 24 Jun, 2013 2 commits
  20. 21 May, 2013 1 commit
    • Dan Winship's avatar
      Use 'dumb quotes' rather than `really dumb quotes' · 4b94c083
      Dan Winship authored
      Back in the far-off twentieth century, it was normal on unix
      workstations for U+0060 GRAVE ACCENT to be drawn as "‛" and for U+0027
      APOSTROPHE to be drawn as "’". This led to the convention of using
      them as poor-man's ‛smart quotes’ in ASCII-only text.
      
      However, "'" is now universally drawn as a vertical line, and "`" at a
      45-degree angle, making them an `odd couple' when used together.
      
      Unfortunately, there are lots of very old strings in glib, and also
      lots of new strings in which people have kept up the old tradition,
      perhaps entirely unaware that it used to not look stupid.
      
      Fix this by just using 'dumb quotes' everywhere.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=700746
      4b94c083
  21. 15 Oct, 2012 1 commit
    • Allison Karlitskaya's avatar
      g_settings_bind: use canonical property name · 1a20d56a
      Allison Karlitskaya authored
      We were using the user-passed value of the @property argument for
      several purposes in g_settings_bind(): error messages, binding
      uniqueness (ie: one-binding-per-property-per-object) and most
      importantly, connecting to the detailed notify:: signal.
      
      The user may pass a string like "property_name" when the property's
      canonical name is "property-name".  g_object_class_find_property() will
      find the property under these circumstances, but a connection to
      "notify::property_name" will not notice notifies emitted for
      "property-name".
      
      We can solve this by using the user's string to perform the lookup and
      then using pspec->name for everything after that.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=684882
      1a20d56a
  22. 06 Jul, 2012 1 commit
  23. 13 Apr, 2012 1 commit
  24. 27 Jan, 2012 1 commit
    • Allison Karlitskaya's avatar
      GSettings: two memory use fixes · da386705
      Allison Karlitskaya authored
      First, correct a rather dubious case of accessing a GSettingsSchemaKey
      after clearing it.  This was technically okay because only the key name
      was accessed (and it is not owned by the struct) but it looks very
      wrong.
      
      Second, have g_settings_backend_write() sink the passed in GVariant*.
      Not all backends get this right, and I'm starting to like the pattern of
      virtual function wrappers being responsible for sinking the parameters
      that they are documented as consuming.
      da386705
  25. 19 Jan, 2012 1 commit
  26. 21 Nov, 2011 1 commit
  27. 18 Nov, 2011 1 commit
  28. 17 Nov, 2011 3 commits