1. 28 Nov, 2014 1 commit
  2. 27 Nov, 2014 1 commit
  3. 25 Nov, 2014 1 commit
  4. 24 Nov, 2014 1 commit
  5. 23 Nov, 2014 3 commits
  6. 22 Nov, 2014 3 commits
  7. 20 Nov, 2014 2 commits
  8. 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
  9. 18 Nov, 2014 1 commit
  10. 15 Nov, 2014 2 commits
  11. 13 Nov, 2014 1 commit
  12. 10 Nov, 2014 1 commit
  13. 09 Nov, 2014 2 commits
  14. 03 Nov, 2014 1 commit
  15. 02 Nov, 2014 1 commit
  16. 01 Nov, 2014 1 commit
  17. 30 Oct, 2014 3 commits
  18. 29 Oct, 2014 1 commit
    • Dan Winship's avatar
      gmain: don't pass the same fd to g_poll() multiple times · b3e3ed73
      Dan Winship authored
      If a given fd is being polled by multiple sources, we used to pass it
      multiple times to g_poll(), which is technically illegal (and not
      supported by the select()-based fallback implementation of poll() in
      gpoll.c), and also made it more likely that we'd exceed the maximum
      number of pollfds.
      
      Fix it to merge together "duplicate" GPollFDs. The easiest way to do
      this involves re-sorting context->poll_records into fd order rather
      than priority order. This means we now have to walk the entire pollrec
      list for every g_main_context_query() and g_main_context_poll(),
      rather than only walking the list up to the current max_priority.
      However, this will only have a noticeable effect if you have tons of
      GPollFDs, and we're already too slow in that case anyway because of
      other O(n) operations that happen too often. So this shouldn't change
      much (and the new poll API will eventually let us be cleverer).
      
      Remove some win32-specific code which did the same thing (but was
      O(n^2)).
      
      https://bugzilla.gnome.org/show_bug.cgi?id=11059
      b3e3ed73
  19. 28 Oct, 2014 1 commit
    • Owen W. Taylor's avatar
      GDBusInterfaceVTable: clarify memory handling for the method() virtual function · 66fc112c
      Owen W. Taylor authored
      There are two consistent interpretations that could be taken for memory
      handling of the 'invocation' parameter passed to the method_call() virtual
      function of GDBusInterfaceVTable
      
       - A reference is passed (transfer full) to the method_call() virtual function,
         and that reference is then passed (transfer full) to the return_value/error
         functions on GDBusMethodInvocation.
       - An internal reference is retained from the point where method_call() is called
         until the return_value/error function is called.
      
      Since the return_value/error functions were already marked (transfer full),
      we use the first interpretation, annotate the invocation parameter of
      method call as (transfer full) and describe this in the documentation, along
      with the idea that you are always supposed to call one of the return_value/error
      functions.
      
      See bug 738122 for the leak this caused in GJS.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=738259
      66fc112c
  20. 27 Oct, 2014 2 commits
  21. 26 Oct, 2014 1 commit
  22. 25 Oct, 2014 1 commit
    • Dan Winship's avatar
      gio/tests/tls-certificates: fix · 0501bf26
      Dan Winship authored
      da053e34 broke the tls-certificates test by requiring the backend to
      implement g_tls_certificate_verify() (which the test TLS backend
      didn't). Add a trivial implementation to make the test pass again;
      we'll need something more complicated when we add tests that are
      supposed to get errors.
      0501bf26
  23. 21 Oct, 2014 6 commits
  24. 20 Oct, 2014 2 commits
    • Allison Karlitskaya's avatar
      GApplication: ignore --help if not handling args · f4af8d1d
      Allison Karlitskaya authored
      If the user didn't register any arguments for parsing, also ignore
      --help.  This fixes a regression in meld.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=737869
      f4af8d1d
    • Allison Karlitskaya's avatar
      GOption: stop calling getopt() · 817f82da
      Allison Karlitskaya authored
      We called getopt() to try to find out of the platform on which we are
      running defaults to strict POSIX-style argument handling (ie: flags
      following the first filename are considered as further filenames rather
      than flags).
      
      This is the default case on BSDs, for example.  It is also the case on
      GNU systems with the POSIXLY_CORRECT environment variable set.
      
      Unfortunately many of our tools rely on being able to accept commandline
      arguments in the non-strict ordering and the code for making these calls
      is spread widely (for example in Makefile fragments invoking some of our
      build tools).
      
      For this reason we need to revert the getopt() check and only enable
      strict POSIX mode in the case that the application explicitly opts into
      it using the _set_strict_posix() API.
      
      This also fixs a failure to build on Windows due to missing getopt().
      
      https://bugzilla.gnome.org/show_bug.cgi?id=723160
      817f82da