Add a new API, gtk_popover_set_default_widget, that can be
used to make a widget act as default while the popover is
shown. This is useful in dialog-like popovers.
http://bugzilla.gnome.org/show_bug.cgi?id=747664
cairo_rectangle_int_t was replaced by GdkRectangle in commit
552c29b488, but the type of the pointing-to
property was not changed.
To avoid breaking old code that sets or gets the property with a GValue
of type CAIRO_GOBJECT_TYPE_RECTANGLE_INT, transformation functions between
CAIRO_GOBJECT_TYPE_RECTANGLE_INT and GDK_TYPE_RECTANGLE are registered on
the first call to gdk_rectangle_get_type().
https://bugzilla.gnome.org/show_bug.cgi?id=723394
These have the same visual effect and timing than the gnome-shell ones.
During the hide animation, the popover has been made to take focus
elsewhere, and refuse to take any pointer/keyboard input until the popover
is shown again.
This has been based on work from Timm Bäder.
https://bugzilla.gnome.org/show_bug.cgi?id=741405
On the wayland backend, set up GDK_WINDOW_SUBSURFACE windows
for popovers. In the popover code, the popover-relative-to-parent
calculation had to be tweaked, and it's been made to always prefer
the given popover position, since there's no sizing limitations.
https://bugzilla.gnome.org/show_bug.cgi?id=738891
All popover sides have extra margins to possibly hold the tail, this is
accounted for in gtk_popover_get_rect_coords(), and should be accounted
for too in the tail position calculation.
This fixes the gtk_render_frame_gap() warnings seen when a popover is
pushed far too close to window sides.
If the previous focus widget is unmapped (eg. hidden, scheduled for
destruction, etc), make the popover forget about it and grant focus
back to the window itself.
gtk_window_propagate_key_event() will run unstopped from the focus widget up to the
popover if GDK_EVENT_PROPAGATE was returned along the chain, resulting in infinite
recursion. This could be just triggered by pressing some modifier key on an entry...
This is the expected behavior while the popover keeps the grab, leaving
this up to the toplevel implementation gives place to key handlers
connected there to handle the event otherwise, and maybe redirect key
events somewhere else.
During size request, all sides' margins are ensured to be as big
as TAIL_HEIGHT, just to avoid possible relocation loops if the
popover doesn't fit in its original position. This must be
accounted for in size_allocate() as well.
- 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
