1. 13 Oct, 2016 1 commit
  2. 11 Mar, 2016 1 commit
  3. 22 Dec, 2014 1 commit
    • Allison Karlitskaya's avatar
      GtkMenuTracker: add hidden-when='macos-menubar' · 6b26664c
      Allison Karlitskaya authored
      Provide a mechanism for hiding the "Quit", "About" and "Preferences"
      menu items from the normal places in a traditional menubar layout (in
      the File and Edit menus) when the menu is being rendered in the Mac OS
      menubar.
      
      These items can already be found in the application menu.
      
      With this feature, applications can now define a single menu to use in
      all 'traditional' scenarios.
      
      Use this new attribute in Bloatpad.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=741610
      6b26664c
  4. 14 Dec, 2014 2 commits
    • Allison Karlitskaya's avatar
      GtkMenuTracker: one more visibility tweak · 4288d7d7
      Allison Karlitskaya authored
      On creation, we call action_removed() in case the action was missing
      from the start.  Because we just created the action, 'can_activate' will
      always be FALSE here and this function will therefore always do nothing.
      
      We do want the visibility state to be updated though, for the case where
      the action is missing but the item should still be visible from the
      start.
      
      Update the visibility directly instead of trying to call
      action_removed().
      
      https://bugzilla.gnome.org/show_bug.cgi?id=735122
      4288d7d7
    • Allison Karlitskaya's avatar
      GtkMenuTrackerItem: fix submenu visibility flag · 8e731560
      Allison Karlitskaya authored
      We were only properly setting the "is-visible" flag to TRUE for menu
      items with associated actions and not (for example) on submenus.
      
      This was fine because the code for building GtkMenus from models
      (correctly) assumed that submenus should always be visible and never
      checked the property.
      
      This is not true for the Mac OS code, which actually checked the
      property and found it to be false for submenus.
      
      Initialise the property to TRUE so that we get the correct value
      reported for items that don't have actions.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=735122
      8e731560
  5. 02 Aug, 2014 1 commit
  6. 29 Jun, 2014 1 commit
  7. 28 Apr, 2014 5 commits
  8. 07 Feb, 2014 1 commit
  9. 22 Jan, 2014 1 commit
  10. 21 Jan, 2014 1 commit
  11. 18 Jan, 2014 1 commit
  12. 12 Jan, 2014 1 commit
  13. 08 Jan, 2014 3 commits
  14. 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.
      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
  15. 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.
      7793f21d
    • 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
      entirely.
      
      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.
      a4276a6c