:toggled is triggered on :clicked, so using :toggled lead to the menu
to be popped up at the same time, while allowing to use the toggle state
and avoiding any need to a hack to prevent recursion, which somehow
wasn't enough for double emission of GtkMenuToolButton:show-popup.
https://bugzilla.gnome.org/show_bug.cgi?id=769287
The visibility toggling happening on ::click() relied implicitly
on the popover animation, but breaks on disabled animations. The
recursion happening within gtk_toggle_button_set_active() (which
triggers ::clicked when changing state) makes this vfunc to run
again, inverting the visibility of the popover in result.
Fix this by explicitly checking about recursion, we want the
button to be toggled to the right state, but we don't want the
callback running again.
https://bugzilla.gnome.org/show_bug.cgi?id=752577
GtkInspector is opening a separate display connection, which makes
it more likely that gtk_get_current_event() returns an event from
the "wrong" display.
We were getting ourselves in trouble by casting touch events
to GdkEventButton and poking directly at their internals. Instead,
use GdkEvent API to get what we need.
This fixes a crash when using the gear menu in epiphany with
touch. The same crash also occurred in testmenubutton.
Rework the way we assign an accessible name to menu buttons,
to make sure we pick up a label, should the button contain
one, and only override the name with "Menu" as a fallback.
This happens on button release, which is more convenient if the gesture
can be consumed by something else (eg. window dragging), and already behaves
correctly wrt cancelled gestures, broken grabs, etc.
This also allows us to unify pointer and keyboard behavior, popping up the
menu widget in a single place.
While a popover is hiding, the modal grab is already gone and the toggle
button is clickable again, but clicking again at that time will result in
gtk_widget_show() trying to show an already shown widget (although fading
out and hidden soon) and the toggle button activated.
So let the menubutton set the active status only if the menu/popover
widget wasn't already shown, and ensure this doesn't get triggered by
double/triple button press events.
As an actionable (inherited from GtkButton), a GtkMenuButton
should not set its own sensitivity when it has an action-name
set, but just follow the enabled state of the associated
action.
https://bugzilla.gnome.org/show_bug.cgi?id=738083
GtkArrow is deprecated and is not used internally anymore by the
menu button. Document also the fact that if no direction is specified
then the view-context-menu icon is shown.
https://bugzilla.gnome.org/show_bug.cgi?id=733441
When constructing from a menu model, use popovers by default.
This change has the potential to cause some size problems for
applications with big gear menus, so we're doing it early in
the cycle to uncover and fix those.
With the code as written, use-popover has to be set first,
before the model. To avoid this ordering dependency, re-set
the model when use-popover changes.
The convention we follow is that the PROP_foo define should
match the property name. Therefore, change PROP_MODEL to
PROP_MENU_MODEL to match "menu-model".
Add api to allow explicitly setting a GtkPopover instead of
a GtkMenu as the popup of a GtkMenuButton. Also, add api to
instruct the menu button to construct a popover when given
a menu model.
We set the style class "menu-button" on the button only when
it pops up a menu, to allow different treatment for the active
state of the button in the two cases.
https://bugzilla.gnome.org/show_bug.cgi?id=723878
The button now claims its menu as a child for a11y purposes,
which makes it possible for ATs to see it when the navigate
the tree top-down.
Update the a11y test to match.
Keyboard activation relies on the menu not being visible,
so ensure that it isn't when the menu is attached.
Problem tracked down by Vincent Le Garrec,
https://bugzilla.gnome.org/show_bug.cgi?id=688738
