1. 23 Oct, 2013 1 commit
  2. 22 Oct, 2013 2 commits
  3. 21 Oct, 2013 5 commits
  4. 18 Oct, 2013 2 commits
  5. 17 Oct, 2013 6 commits
  6. 16 Oct, 2013 10 commits
  7. 15 Oct, 2013 13 commits
    • Matthias Clasen's avatar
      Wayland: avoid accidental export of internal symbols · 0db75c6b
      Matthias Clasen authored
      Some symbols in the generated Wayland code were getting
      decorated with WL_EXPORT, causing them to show up in the
      libgdk exports. We don't want that.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=710141
      0db75c6b
    • Piotr Drąg's avatar
      Updated POTFILES.in · 6372342a
      Piotr Drąg authored
      6372342a
    • Matthias Clasen's avatar
      Wayland: fix a crash in opaque region handling · 73bae5b8
      Matthias Clasen authored
      We may get a NULL region passed to the backend, which means
      'nothing is opaque'. In that case, don't crash, but pass
      the information on to the compositor.
      
      http://bugzilla.gnome.org/show_bug.cgi?id=709854
      73bae5b8
    • Allison Karlitskaya's avatar
      bloatpad: test dynamic accels · db7115d8
      Allison Karlitskaya authored
      ...this stuff will be in the action description soon.
      db7115d8
    • Allison Karlitskaya's avatar
      GtkApplication: a new approach to accels · 9a6ee36e
      Allison Karlitskaya authored
      Rework how accels are handled on GtkApplicationWindow.
      
      Instead of having GtkApplication fill the GtkAccelMap which is then used
      by GtkApplicationWindow to create a GtkAccelGroup filled with closures
      that is then associated with the window, do it directly.
      
      GtkApplication now keeps a list of accels and their actions.
      Accelerators on a GtkApplicationWindow ask GtkApplication to execute the
      appropriate action.
      
      This saves a fair bit of complexity and memory use (due to not having to
      create all those closures and accelmap entries).  The new approach also
      supports multiple accels per action (although there is not yet a public
      API for it).
      
      This patch (and the ones before) Reviewed and ACK'd by Matthias Clasen.
      9a6ee36e
    • Allison Karlitskaya's avatar
      GtkMenuTrackerItem: add support for dynamic accels · afa8b017
      Allison Karlitskaya authored
      Add support for pulling the primary accel out of the GtkActionMuxer.
      
      With this change, it is no longer necessary to have the accel=''
      attribute hardcoded onto each menu item (and, in fact, it should be left
      off if you intend to have support for dynamic accelerator changing).
      
      Specifying accel='' is a good way to force an accelerator not to be
      displayed on a menu item.
      afa8b017
    • Allison Karlitskaya's avatar
      GtkMenuTrackerItem: use "action and target" format · 2074dacc
      Allison Karlitskaya authored
      Store "action and target" format inside each GtkMenuTrackerItem.  This
      makes action invocation more efficient (no hash table lookups or
      allocations) and slightly simplifies handling of action namespace.
      
      More importantly, this will be used when we start to get accels from
      GtkActionMuxer.
      2074dacc
    • Allison Karlitskaya's avatar
      GtkActionMuxer: store primary accels · 3f8c2355
      Allison Karlitskaya authored
      Reuse the existing infrastructure in GtkActionMuxer for propagation of
      accelerator information: in particular, what accel label ought to appear
      on menu items for a particular action and target.
      
      This is a good idea because we want accels to travel along with the
      actions that they're tied to and reusing GtkActionMuxer will allow us to
      do that without creating another hierarchy of a different class for the
      sole purpose of filling in accel labels on menu items.
      
      Doing it this ways also allows those who copy/paste GtkActionMuxer to
      insert the accels for themselves.
      
      Add a new method on the GtkActionObserver interface to report changes.
      
      This patch introduces a new concept: "action and target" notation for
      actions.  This format looks like so:
      
        "'target'|app.action"
      
      or for non-targeted actions:
      
        "|app.action"
      
      and it is used over a number of possible alternative formats for some
      good reasons:
      
       - it's very easy to get a nul-terminated action name out of this format
         when we need it, by using strrchr('|') + 1
      
       - we can also get the target out of it using g_variant_parse() because
         this function takes a pointer to a 'limit' character that is not
         parsed past: we use the '|' for this
      
       - it's extremely easy to hash on this format (just use a normal string
         hash) vs. attempting to hash on a string plus a GVariant
      
      A close contender was to use detailed action strings here, but these are
      not used for two reasons:
      
       - it's not possible to easily get the action name or target out of the
         strings without more work than the "action and target" format
         requires
      
       - we still intend to use detailed action strings on API (since they are
         a lot nicer to look at) but detailed action strings can be given in
         non-canonical forms (eg: 'foo::bar' and 'foo("bar")' are equivalent)
         so we'd have to go through a normalisation step anyway.  Since we're
         doing that already, we may as well convert to a more convenient
         internal format.
      
      This new "action and target" format is going to start appearing in a lot
      more places as action descriptions are introduced.
      
      I suspect that nobody is using '|' in their action names, but in case I
      am proven wrong, we can always switch to using something more exotic as
      a separator character (such as '\x01' or '\xff' or the like).
      3f8c2355
    • Allison Karlitskaya's avatar
      GtkWindow: change muxer setup with application · abcddd3a
      Allison Karlitskaya authored
      Previously, GtkWindow would add the "app" action group to its own
      toplevel muxer.
      
      Change the setup so that GtkApplication creates the toplevel muxer and
      adds itself to it as "app".  Use this muxer as the parent muxer of any
      GtkWindow associated with the application.
      
      This saves a small amount of memory and will allow for accels to be
      propagated from the application through to all of the windows.
      abcddd3a
    • Allison Karlitskaya's avatar
      GtkBuilder: add GtkApplication · 3f0b9a75
      Allison Karlitskaya authored
      Add a GtkApplication (private) field to GtkBuilder
      3f0b9a75
    • Matthias Clasen's avatar
      Fix a crash in icon handling · d967266b
      Matthias Clasen authored
      The load_error was freed in two places.
      Fix based on a patch in
      https://bugzilla.gnome.org/show_bug.cgi?id=709967
      d967266b
    • Daniel Mustieles García's avatar
      Updated Spanish translation · 999b5243
      Daniel Mustieles García authored
      999b5243
    • Andika Triwidada's avatar
      Updated Indonesian translation · b19af93b
      Andika Triwidada authored
      b19af93b
  8. 14 Oct, 2013 1 commit
    • Matthias Clasen's avatar
      Restore accessible names for image-only buttons · f9c8fefe
      Matthias Clasen authored
      With the stock system being deprecated now, we should provide
      meaningful accessible names for buttons that are constructed
      from icon names or GIcons. This commit reuses the existing
      translations.
      
      It is possible that some common icon names are not covered
      here because they were not present as stock items. These can
      be added to the table later.
      f9c8fefe