1. 05 Feb, 2015 1 commit
  2. 28 Nov, 2014 1 commit
  3. 11 Oct, 2014 1 commit
  4. 28 Jun, 2014 1 commit
  5. 24 Jun, 2014 1 commit
  6. 31 May, 2014 1 commit
  7. 09 May, 2014 1 commit
  8. 06 Feb, 2014 1 commit
  9. 01 Feb, 2014 3 commits
  10. 31 Jan, 2014 2 commits
  11. 04 Dec, 2013 1 commit
  12. 03 Dec, 2013 1 commit
  13. 02 Sep, 2013 2 commits
  14. 29 Jul, 2013 1 commit
  15. 24 May, 2013 1 commit
    • Allison Karlitskaya's avatar
      gsignal: remove some pointless locking · 3d1d4917
      Allison Karlitskaya authored
      We previously hold a lock in the loop that collects the arguments for
      g_signal_emit(), which we drop before calling into the argument
      collection functions and reacquire again at the bottom of the loop (ie:
      one release/acquire pair for each argument collected).  To make matters
      worse, the lock is just released again after the loop.
      
      Presumably that was done to protect the access to the parameter array,
      but it's pretty unlikely that this is needed because the only way it
      changes is if the signal is unloaded.  That only happens when unloading
      types which is quite unlikely to happen while we are emitting on an
      instance of that type (and, as an aside, never happens anymore anyway).
      
      If we move the unlock below the loop up above it and remove the
      acquire/release pair from the loop, we improve performance in the new
      arg-collecting performance tests by ~15% (more like ~18% in the case
      where we only emit to one handler -- where argument collection dominates
      more).
      
      https://bugzilla.gnome.org/show_bug.cgi?id=694380
      3d1d4917
  16. 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
  17. 22 Feb, 2013 1 commit
  18. 21 Feb, 2013 2 commits
  19. 17 Jan, 2013 1 commit
    • Allison Karlitskaya's avatar
      gsignal: fix closure invalidation code · d89fb7bf
      Allison Karlitskaya authored
      This is the bug that has been causing segfaults and criticals when accel
      keys are used to close windows via GtkUIManager.
      
      The main cause of this problem was a mistake made in the original patch
      when modifying the handler_lookup() to take the extra 'closure'
      parameter.  The original check used was:
      
          if (handler->sequential_number == handler_id ||
             (closure && handler->closure == closure))
      
      It was called to find a particular closure like so:
      
          handler_lookup (instance, 0, closure, &signal_id);
      
      The problem is that the check will return if either the signal ID or
      closure matches (if a closure was given).  The calling code assumes 0 to
      be an invalid signal ID which will match no handlers, but unfortunately
      the rest of gsignal code uses this to denote a signal that has already
      been disconnected.  The result is that this function was searching for a
      matching closure _or_ the first already-disconnected handler.  When it
      found the already-disconnected handler, we'd get criticals and crashes.
      
      The condition has been corrected; it now ignores the handler_id
      parameter if the closure parameter is non-NULL.
      
      While we're in here, change the lifecycle of the invalidation notify to
      be easier to understand.
      
      Before, the notify was removed when the last reference on the handler
      dropped.  This could happen in very many situations; often at the end of
      an emission.  Instead, we now tie the registration of the notifier to
      the lifecycle of the signal connection.  When the signal is disconnected
      we remove the notification, even if other references are held (eg:
      because it is currently being dispatched).
      
      https://bugzilla.gnome.org/show_bug.cgi?id=690118
      d89fb7bf
  20. 13 Oct, 2012 1 commit
  21. 08 Oct, 2012 2 commits
    • Allison Karlitskaya's avatar
      [gsignal] fix up a crasher in previous commit · c15769d3
      Allison Karlitskaya authored
      The previous commit introduced a new variable in the Handler struct but
      didn't initialise it.  This was causing some tests to crash.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=118536
      c15769d3
    • Matthias Clasen's avatar
      [gsignal] disconnect invalidated closures · d03d26fe
      Matthias Clasen authored
      Modify gsignal to automatically disconnect a GClosure that becomes
      invalid (in the g_closure_invalidate() sense).
      
      Previously, when g_signal_connect_object() was used with a GObject as
      the user_data and that object was destroyed, the handler would no longer
      be called but the signal handler was itself was not disconnected (ie:
      the bookkeeping data was kept around).
      
      The main effect of this patch is that these signal handlers will now
      be automatically disconnected (and fully freed).
      
      The documentation for g_signal_connect_object() has anticipated this
      change for over 10 years and has advised the following workaround when
      disconnecting signal handlers connected with g_signal_connect_object():
      
       if (g_signal_handler_is_connected (instance, id))
         g_signal_handler_disconnect (instance, id);
      
      If your code follows this practice then it will continue to work.
      
      If your code never disconnects the signal handler then it was wasting
      memory before (and this commit fixes that).
      
      If your code unconditionally disconnects the signal handler then you
      will start to see (harmless) g_critical() warnings about this and you
      should fix them.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=118536
      d03d26fe
  22. 22 Jun, 2012 1 commit
  23. 14 Mar, 2012 1 commit
  24. 09 Mar, 2012 2 commits
  25. 07 Mar, 2012 1 commit
  26. 06 Mar, 2012 1 commit
  27. 05 Mar, 2012 1 commit
  28. 03 Mar, 2012 1 commit
  29. 02 Mar, 2012 5 commits