- gtk_style_context_get_background_color()
- gtk_style_context_get_border_color()
Those functions shouldn't be used anymore, because they don't represent
anything from the CSS styling we support. The background color often
isn't used due to background images and there are actually 4 different
border colors (1 for each side) - if there isn't also a border image in
use.
A popover can go unmanaged for 2 reasons, when the widget it points to
gets destroyed, or transitionally in gtk_popover_set_relative_to(). In
both of these cases it makes sense to only unset popover information
about the previous widget managing it, if the popover is meant to
survive the unmanaging through extra refs.
Also, the focus widget prior to a modal popover being shown is considered
information about the relative_to widget, unset it on
gtk_popover_update_relative_to() with the rest.
https://bugzilla.gnome.org/show_bug.cgi?id=736193
There was some confusion between unflipped and flipped positions.
Both final_position and current_position are meant to be unflipped,
and get_effective_position() needs to be applied to them to get
a flipped position. _gtk_window_set_popover_position() also expects
an unflipped position.
https://bugzilla.gnome.org/show_bug.cgi?id=735014
Popovers may get relocations optimized away if only x/y changed
in the GtkAllocation. So make sure the toplevel updates popover
positions on all situations.
https://bugzilla.gnome.org/show_bug.cgi?id=729140
The focus widget might be unset, just to be set again on a widget inside
the popover. Have the popover wait till the focus is actually moved outside
before dismissing.
Make the relative_to widget the parent for a GtkPopover's
GtkActionGroup. This, for example, makes the menu model of a
GtkMenuButton find action groups attached to the button.
https://bugzilla.gnome.org/show_bug.cgi?id=729915
Now that popovers may snap to any side with enough space, make enough
room on every side when requesting size, so that there's no w/h differences
at the time of setting the child allocation.
https://bugzilla.gnome.org/show_bug.cgi?id=729097
Instead of using GtkMenuTracker to flatten the sections into a single
linear menu, handle the sections ourselves by nesting boxes.
Each section gets an inner and outer box. The inner box numbers its
children in the way that the tracker instructs. The outer box
containes the inner box and the separator, if appropriate.
Having the two separate boxes will allow us to change the orientation of
the inner box if we want to pack widgets horizontally within a section.
Add the possibility of a GtkMenuTracker that performs no section
merging. Instead, it will report an item in the form of a separator for
subsections. It is then possible to get a separate tracker for the
subsection contents by using gtk_menu_tracker_new_for_item_link().
We have some API in GtkMenuTracker and GtkMenuTrackerItem that is
specifically designed to deal with submenus.
Generalise these APIs to take a 'link_name' parameter that we always
give as G_MENU_SUBMENU for now. In the future, this will allow creating
trackers for other types of links, such as sections.
And let GtkPopover use it as its GtkAccessible implementation, this
accessible sets the POPUP_FOR relationship to the relative-to widget,
and keeps track of changes there.
https://bugzilla.gnome.org/show_bug.cgi?id=725864
Make the popover temporarily undo the GTK+ grab, so it remains modal
to its window, but does not attempt to steal focus on other non-modal
windows that get the focus.
This was most confusing with keyboard navigation, as the focus would
remain stuck on the popover, and not move to the newly focused window
after the popover was dismissed. It didn't have as much effect on
pointer operations as only the first click would be consumed in order
to hide the popover.
This is not necessary for the popover itself, but helps tooltips
code confine the widget lookup within the popover if the pointer
is inside it, otherwise the widget lookup may turn out wrong for
motion events, starting the tooltip widget lookup from the toplevel
window, mistakenly triggering tooltips on the natural window
descendants (ie. the widget below the popover)
https://bugzilla.gnome.org/show_bug.cgi?id=724785
In practice this shape is only used to outline the popover when it is
above native windows, in the most normal full-csw case the shape won't apply
visibly, so popovers will still be able to cast a shadow there.
If there are native windows below the popover, the shape will exclude the
shadow, so there are no alpha contents above the window. One worst case that
might happen is that the popover lays above patches of native/client-side
windows, so the shadow could come and go around the border. But first let's
see whether that happens often or visibly enough before adding something more
convoluted.
And document the fact that the popover will get destroyed if
a NULL relative-to is given on a parented popover, if no extra
references are kept.
For gtk_popover_new*(), a NULL relative-to will leave the widget
as a floating object, to be sunk by a later call to
gtk_widget_set_relative_to().
https://bugzilla.gnome.org/show_bug.cgi?id=724407
The with_separators argument does not really make sense
for popovers, it was just copied from the menu implementation.
Drop it now, before it becomes part of the public API.
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.
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
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
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.
Popovers no longer sets a shape, unless this function is called. This
function exists so widgets that are potentially placed on top of other
native windows can get a popover that's nicely shaped, even if it has
no border shadow around.
https://bugzilla.gnome.org/show_bug.cgi?id=723556
The minimal size if no child widget was present/shown was far too small
to have enough room for the arrow width plus border radii, so
gtk_render_frame_gap would spew warnings about the gap being out of
boundaries.
Fixes issues seen in
https://bugzilla.gnome.org/show_bug.cgi?id=723031#c2
If the grab is released during button press, the button release is
just then sent to the widget below the pointer. Depending on the
widget implementation, this could already trigger actions if the
widget does not perform any kind of button state tracking. It is
safer to ungrab on button release so no extra actions are possibly
triggered, and the behavior is uniform across widgets.
But the opposite situation may also happen, that a popover is
shown/grabbed on a button press event, so it'd get the sole button
release event after being shown, so prepare for that case by making
popover ignore single button release events with no preceding button
press.
Fixes issues seen in
https://bugzilla.gnome.org/show_bug.cgi?id=723031#c2
It was only done so the background would connect visually to the popover
tail, but then it brings aliasing issues when the border is drawn over the
background. Instead, overdraw the tail, so it also fills the gap left by
the border.
