We don't want the size request to change as icons come and
go (thinking e.g. about the caps lock warning). Just make
sure that we have enough room for showing the icons.
Improve the algorithm to determing popover placement:
If it fits in the preferred direction or its opposite,
do that, otherwise use the direction that causes the least
of the popover to be cut off.
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
cairo_rectangle_int_t replaced by GdkRectangle whenever it is used.
Also, rect parameter in public method gtk_popover_set_pointing_to
made const.
Bug #723394
Replace GTK_TYPE_WIDGET with more specific GTK_TYPE_FLOW_BOX_CHILD
for GtkFlowBox::child-activated. This matches signature of
child_activated slot in class struct.
https://bugzilla.gnome.org/show_bug.cgi?id=723716
The properties are declared read-write, but only the setter
was hooked up. This was leading to criticals in test apps using
the prop-editor.c code. Complete the implementation by adding the
getter side too.
This adds a new function, gtk_popover_new_from_model, which creates
a popover and populates it with suitable content according to the
menu model. The current implementation uses GtkModelButton for the
individual items, and a GtkStack for submenus.
https://bugzilla.gnome.org/show_bug.cgi?id=723014
Similar in spirit to GtkModelMenuItem, this private GtkButton subclass
can connect to a GtkMenuTrackerItem and present itself as either a
regular button, a check button, or a radio button. Activation and
state tracking is done through the GAction that is associated with
the menu tracker item.
https://bugzilla.gnome.org/show_bug.cgi?id=723014
Popovers aren't direct children of the widget they point to, but yet
they act as children of it, so do the same with state propagation,
so the flags that propagate across the hierarchy reach popovers too.
Anytime ::grab-notify comes across, the popover visibility and GTK+
grab ownership are checked, so the popover is hidden when it loses
the GTK+ by any reason.
Previously we did a semi-successful job at ignoring it. Unfortunately
this job was bad enough that we could lose the direction.
We still allow passing in the enum values, because we want code like
this to work:
set_state_flags (get_state_flags() | SOME_FLAGS)
Heavy duty can prevent this idle function from being called before
the window is destroyed, so make sure that the source is removed
when the window is finalized.
https://bugzilla.gnome.org/show_bug.cgi?id=723771
