GtkMenu calls gtk_widget_size_allocate on its GtkWindow during
gtk_menu_popup_for_device if the menu has not been realised. This can cause the
allocation of the GtkWindow and the size of the GdkWindow to become out of sync
because a top level GtkWindow does not attempt to re-size the GdkWindow when
its allocation is set.
https://bugzilla.gnome.org/show_bug.cgi?id=695120
This replaces the previously hardcoded calls to gdk_window_set_user_data,
and also lets us track which windows are a part of a widget. Old code
should continue working as is, but new features that require the
windows may not work perfectly.
We need this for the transparent widget support to work, as we need
to specially mark the windows of child widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=687842
Make the main (and only) entry-point to gtkmodelmenu.c the now-public
gtk_menu_shell_bind_model().
Move the convenience constructors (gtk_menu_new_from_model() and
gtk_menu_bar_new_from_model()) to their proper files.
Remove the private header file.
Simplify the code a bit by making the initial populate part of the
bind() call.
https://bugzilla.gnome.org/show_bug.cgi?id=682831
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.
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
When the menu is detached, the attach-widget property changes value to
NULL, so we should notify a property change, like
gtk_menu_attach_to_widget() does.
https://bugzilla.gnome.org/show_bug.cgi?id=679454
This was broken since before GTK+ 3.0, when we replaced
a use of requisition by allocation. Fix this by using the
requisition height, that is already cached by the menu code.
The math is not quite right here; if you page all the way
down a long menu, you end up on the second-to-last menuitem.
But at least, page up/down let you move up and down the menu
again.
https://bugzilla.gnome.org/show_bug.cgi?id=668931
Add an internal API that allows GtkStyleContext to create a widget path
for the widget and with that bypassing gtk_widget_get_path() and that
function caching the path.
This is so submenus stay open as the parent menu item is
pressed/released, since the user would typically lift the
finger in order to select a submenu item.
If the display server or GDK hides the window - fire the "deactivate" signal
to ensure that the internal state is consistent.
This patch also ensures that the "deactivate" signal will not be fired for a
menu that is not active.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=670881
gtk_window_get/set_attached_to() is a new API that allows for windows to
be attached to a GtkWidget.
The attachment is a logical binding between the toplevel window and the
widget that generated it; this kind of information is currently used to
propagate style information from the widget to the window, but is also
useful e.g. for accessibility.
https://bugzilla.gnome.org/show_bug.cgi?id=666103
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
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()
We want the menu realized so we know the size it's allocating to itself.
And we need that size to position the menu properly.
This is best visible on right-to-left.
Lots of code calls gtk_menu_popup() and we don't want to resize the
window needlessly.
In this particular case, keyboard navigation to submenus caused those
submenus to shrink.
Note: I'm not sure this fix doesn't have nasty side effects, as I'm not
a specialist on menu popup code, so if it does, we'll need to revert it.
Until then, let's keep it, it fixes a bug.
