1. 07 Feb, 2014 1 commit
  2. 22 Jan, 2014 1 commit
  3. 21 Jan, 2014 1 commit
  4. 18 Jan, 2014 1 commit
  5. 12 Jan, 2014 1 commit
  6. 08 Jan, 2014 3 commits
  7. 15 Oct, 2013 2 commits
    • 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.
    • 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
  8. 13 May, 2013 3 commits
    • Jasper St. Pierre's avatar
      gtkmenutrackeritem: Simplify the submenu opening API · 7793f21d
      Jasper St. Pierre authored
      Instead of making clients inspect the submenu action and decide what
      to do based upon that, always request the submenu open and let the
      tracker decide what to do.
    • Jasper St. Pierre's avatar
    • Allison Karlitskaya's avatar
      add GtkMenuTrackerItem · a4276a6c
      Allison Karlitskaya authored
      Add a new class, GtkMenuTrackerItem that represents a menu item, to be
      used with GtkMenuTracker.
      GtkMenuTracker's insert callback now works in terms of this new type
      (instead of passing reference to the model and an index to the item).
      GtkMenuShell now handles all of the binding tasks internally, mostly
      through the use of property bindings.  Having bindings for the label and
      visibility attributes, in partiular, will help with supporting upcoming
      extensions to GMenuModel.
      GtkModelMenu has been reduced to a helper class that has nothing to do
      with GMenuModel.  It represents something closer to an "ideal" API for
      GtkMenuItem if we didn't have compatibility concerns (eg: not emitting
      "activate" when setting toggle state, no separate subclasses per menu
      item type, supporting icons, etc.) Improvements to GtkMenuItem could
      eventually shrink the size of this class or remove the need for it
      Some GtkActionHelper functionality has been duplicated in
      GtkMenuTracker, which is suboptimal.  The duplication exists so that
      other codebases (such as Unity and gnome-shell) can reuse the
      GtkMenuTracker code, whereas GtkActionHelper is very much tied to
      GtkWidget.  Supporting binding arbitrary GtkWidgets to actions vs.
      supporting the full range of GMenuModel features for menu items turns
      out to be two overlapping but not entirely similar problems.  Some of
      the duplication (such as roles) can be removed from GtkActionHelper once
      Gtk's internal Mac OS menubar support is ported to GtkMenuTracker.
      The intent to reuse the code outside of Gtk is also the reason for the
      unusual treatment of the enum type introduced in this comment.
      This adds no new "public" API to the Gtk library, other than types that
      we cannot make private due to GType limitations.