1. 17 Sep, 2012 1 commit
  2. 20 Aug, 2012 1 commit
    • Lars Uebernickel's avatar
      GtkWidget: Add gtk_widget_insert_action_group() · d30d5645
      Lars Uebernickel authored
      This allows adding a GActionGroup with a given name at an arbitrary
      point in the widget tree.
      
      This patch also adds an internal _get_action_muxer() API.  Calling this
      will create a GActionMuxer associated with the widget.  The parent of
      the muxer will be the muxer of the widget's conceptual parent.  For
      non-menus, that is the normal parent.  For menus, it is the attach
      widget.
      
      In this way, we end up with a hierarchy of GActionMuxer that largely
      reflects the hierarchy of GtkWidget, but only in places that the action
      context has been requested.  These muxers are the ones on which the
      inserted actions groups are installed.
      
      A following patch will add a user of this API.
      d30d5645
  3. 13 Jul, 2012 3 commits
    • Carlos Garnacho's avatar
      menu: Fix touch scrolling on menus close to the monitor edge · bd3ca2b3
      Carlos Garnacho authored
      Specially in the case of comboboxes, those menus could enable scrolling
      even if the contents could fit in the work area, and could show blank
      space in order to line up the selected item with the combobox.
      
      When such thing happens, take into account scroll_offset when relocating
      the menu contents so contents don't jump directly onscreen, and apply
      it so scrolling is allowed in the direction that brings the menu onscreen
      and blocked in the opposite direction.
      
      Also, wait for cancelling the scroll operation until the touch is released
      even if the scrolling arrows disappeared, so the menu item underneath isn't
      selected right away.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=678113
      bd3ca2b3
    • Carlos Garnacho's avatar
      menu: small code cleanup · 36bcb3bf
      Carlos Garnacho authored
      Don't check twice for the widget being realized to move
      both windows
      36bcb3bf
    • Carlos Garnacho's avatar
      menu: code style fix · 10fa0913
      Carlos Garnacho authored
      The newline before != looks unintentional
      10fa0913
  4. 06 Jul, 2012 1 commit
  5. 02 Jul, 2012 1 commit
  6. 25 Jun, 2012 1 commit
  7. 25 Apr, 2012 1 commit
  8. 17 Apr, 2012 1 commit
  9. 13 Apr, 2012 1 commit
  10. 07 Apr, 2012 1 commit
  11. 19 Mar, 2012 2 commits
  12. 03 Mar, 2012 1 commit
  13. 01 Mar, 2012 6 commits
  14. 29 Feb, 2012 1 commit
  15. 27 Feb, 2012 1 commit
  16. 27 Jan, 2012 1 commit
  17. 26 Jan, 2012 1 commit
  18. 12 Jan, 2012 1 commit
  19. 06 Jan, 2012 1 commit
    • Matthias Clasen's avatar
      Another attempt at fixing menu positioning corner cases · c74ac081
      Matthias Clasen authored
      The code for moving the menu into monitor / workarea was duplicated,
      once for the push-in scenario and once for without. The problem with
      the second case is that we've stored the menu position before adjusting
      it. That made us remember an out-of-monitor position that then later
      triggered _another_ copy of this code in the size-request implementation.
      
      Unify this to only have one copy of code, and only store the menu
      position after adjusting it to be inside the monitor. This fixes both
      statusicon menus that get popped up from the panel, outside the workarea,
      to not have scroll arrows, and the gedit language menu which was not
      placed in the monitor at all after the initial workarea commit.
      
      As a side-effect of this change, we now make large scrolling menus
      occupy the full height of the workarea. Before this change, we were
      keeping either the top or bottom edge put while shrinking the menu
      to fit in the monitor.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=667249
      c74ac081
  20. 23 Dec, 2011 5 commits
  21. 18 Dec, 2011 1 commit
  22. 18 Nov, 2011 1 commit
    • Michael Natterer's avatar
      Bug 663856 - Make option-foo accelerators use the right symbol · 1c8481a6
      Michael Natterer authored
      If the keyboard group shifting modifier is *also* a normal
      accelerator modifier, we need to special case it when calling
      gdk_keymap_translate_keyboard_state(), so we get the right
      key symbol for accelerators (for example we want Option-O,
      not Option-Ø displayed in menu items). This patch should only
      affect quartz where the Alt key both shifts the group and can
      be used as accel modifier, and not X11 or Win32 where AltGr
      is not used for accelerators.
      
      - fix quartz' gdk_keymap_translate_keyboard_state() to return
        the right consumed_modifiers
      - add _gtk_translate_keyboard_accel_state() which does the
        special casing
      - use it everywhere instead of gdk_keymap_translate_keyboard_state()
      1c8481a6
  23. 02 Nov, 2011 2 commits
  24. 01 Oct, 2011 1 commit
  25. 28 Aug, 2011 1 commit
  26. 05 Jul, 2011 1 commit
  27. 10 Jun, 2011 1 commit