1. 23 Apr, 2013 4 commits
  2. 22 Apr, 2013 9 commits
    • Allison Karlitskaya's avatar
      Revert "GObject: prevent installing properties after init" · e8438f98
      Allison Karlitskaya authored
      This reverts commit ddb0ce14.
      
      Colin's smoke testing has found issues in at least gjs and
      gnome-settings-daemon.  We'll need to see if we can address those.
      e8438f98
    • Allison Karlitskaya's avatar
      GObject: prevent installing properties after init · ddb0ce14
      Allison Karlitskaya authored
      GObject has previously allowed installing properties after class_init
      has finished running.  This means that you could install some of your
      own properties on G_TYPE_OBJECT, for example, although they wouldn't
      have worked properly.
      
      Prevent this from happening.  Require that all properties are installed by
      the time class_init has finished.
      
      Complaints go to this bug:
      
      https://bugzilla.gnome.org/show_bug.cgi?id=698614
      ddb0ce14
    • Allison Karlitskaya's avatar
      gtype: put private data before the instance · 31fde567
      Allison Karlitskaya authored
      Classically, a GTypeInstance has had the following layout:
      
       [[[[GTypeInstance] GObject] TypeA] TypeB] [TypeAPrivate] [TypeBPrivate]
      
      where TypeB is a subclass of TypeA which is a GObject.  Both TypeA and
      TypeB use pivate data.
      
      The main problem with this approach is that the offset between a pointer
      to an instance of TypeA and the TypeAPrivate is not constant: it changes
      depending on the depth of derivation and the size of the instance
      structures of the derived types.  For example, changing the size of the
      TypeB structure in the above example would push the TypeAPrivate further
      along.
      
      This complicates the implementation of g_type_instance_get_private().
      In particular, during object construction when the class pointer to the
      'complete type' of the object is not yet stored in the header of the
      GTypeInstance, we need a lookup table in order to be able to implement
      g_type_instance_get_private() accurately.
      
      We can avoid this problem by storing the private data before the
      structures, in reverse order, like so:
      
        [TypeBPrivate] [TypeAPrivate] [[[[GTypeInstance] GObject] TypeA] TypeB]
      
      Now the distance between TypeA and TypeAPrivate depends only on the size
      of GObject and GTypeInstance, which are static.  Even in the case of
      TypeB, the distance is not statically known but can be determined at
      runtime and is constant (because we will know the size of TypeAPrivate
      by the time we initialise TypeB and it won't change).
      
      This approach requires a slighty dirty trick: allocating extra memory
      _before_ the pointer we return from g_type_create_instance().  The main
      problem with this is that it will cause valgrind to behave very badly,
      reporting almost everything as "possibly lost".
      
      We can correct for this by including a few valgrind client requests in
      order to inform it that the start of the GTypeInstance should be
      considered a block of memory and that pointers to it should mean that
      this block is reachable.  In order to make the private data reachable,
      we also declare it as a block and include an extra pointer from the end
      of the primary block pointing back at it.  All of this is only done if
      we are running under Valgrind.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=698595
      31fde567
    • Allison Karlitskaya's avatar
      gslice: disable by default under valgrind · 00fbc2f0
      Allison Karlitskaya authored
      All experienced GLib hackers know that G_SLICE=always-malloc is
      absolutely essential when valgrinding but many users of GLib don't know
      about this and get hit pretty hard when valgrinding their programs.
      
      When initialising gslice, add a check to see if we are running under
      valgrind and disable ourselves if we are.
      
      We only do the check in the case that G_SLICE= was not specified in the
      environment, so setting it to an empty string will prevent this default
      behaviour.
      
      I considered modifying gslice to use the VALGRIND_MALLOCLIKE_BLOCK
      client request in all cases in order to just mark the blocks properly
      but these calls are not free and gslice is pretty hyper-optimised.  It's
      easier to just disable gslice completely and this way we only have to do
      one check during startup.  It's also theoretically possible that someone
      might want to use valgrind to debug gslice, in which case the extra
      annotations would probably cause quite a lot of difficulty.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=698595
      00fbc2f0
    • Allison Karlitskaya's avatar
      Add a copy of valgrind.h to glib/ · c8d56d7c
      Allison Karlitskaya authored
      This is a BSD-licenced header file that is designed to be copy-pasted
      into programs.  It will allow us to detect if we are running under
      Valgrind and send "client requests" to it.
      
      We will use this for a couple of reasons in upcoming patches.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=698595
      c8d56d7c
    • Allison Karlitskaya's avatar
      GMenu: add g_menu_item_set_icon() convenience · c1c1b33f
      Allison Karlitskaya authored
      This function takes a GIcon, serialises it and sets the resulting
      GVariant as the "icon" attribute on the menu item.  We will need to add
      a patch to Gtk to actually consume this icon.
      
      Also add G_MENU_ATTRIBUTE_ICON.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=688820
      c1c1b33f
    • Jasper St. Pierre's avatar
      tests: Fix appinfo test · 63a0cc3f
      Jasper St. Pierre authored
      63a0cc3f
    • Daniel Mustieles García's avatar
      Updated Spanish translation · 709ade0e
      Daniel Mustieles García authored
      709ade0e
    • Sweta Kothari's avatar
      Updated gujarati file · 93349e6e
      Sweta Kothari authored
      93349e6e
  3. 21 Apr, 2013 6 commits
  4. 20 Apr, 2013 2 commits
  5. 19 Apr, 2013 5 commits
  6. 17 Apr, 2013 1 commit
  7. 16 Apr, 2013 3 commits
  8. 12 Apr, 2013 3 commits
  9. 11 Apr, 2013 1 commit
  10. 10 Apr, 2013 6 commits