The effect of transitions-enabled=true can now be
achieved using gtk_popover_popup/popdown and the effect
of transitions-enabled=false can be achieved using
gtk_widget_show/hide.
https://bugzilla.gnome.org/show_bug.cgi?id=769706
Since not chaining up in gtk_widget_show/gtk_widget_hide is not allowed,
we can't just implicitly delay the hiding in GtkPopover's hide
implementation. Fix this by introducing gtk_popover_popup() and
gtk_popover_popdown() to show or hide a popover with transition and
revert GtkPopover's show/hide implementation to apply their effect
without the transition.
https://bugzilla.gnome.org/show_bug.cgi?id=769706
If there are widget margins set, the whole popover will be displaced.
However the calculation of the tail position doesn't have this into
account, ending up with the tail being detached from the popover if
the margin grew too big.
We should not render the arrows invariably next to the GdkWindow edge,
but optionally displaced inside it depending on the widget margins.
Fixes the gtk3-demo "Popovers" demo case, whose GtkEntry popovers set
widget margins for some reason.
https://bugzilla.gnome.org/show_bug.cgi?id=767851
Commit a01fe14 changed the behaviour of popovers when the focus leaves
them to stop child popovers being hidden when the focus leaves their
parent. However they are now a bit too reluctant to hide - if the
focus passes to an unrelated popover the first popover is not
hidden. Also if the focus passes to another widget that does not
perform a gtk grab then the popover isn't hidden until the user
presses a non-movement key or clicks outside the popover.
The solution is to go back to checking if the focused widget is a
descendant of the popover, but to include popovers and their related
widgets in the ancestry chain.
https://bugzilla.gnome.org/show_bug.cgi?id=765595
If the popover's relative-to widget is unparented/reparented, we end
up unparenting/reparenting the popover as well. In that case, at the
moment of reparenting, the widget might have been visible (and is
thus mapped again), but priv->window hasn't been set yet.
We must first set priv->window, and then call gtk_window_add_popover(),
that way gtk_popover_map() has its prerequisites straight.
https://bugzilla.gnome.org/show_bug.cgi?id=766323
If the background is transparent, we can't use it for the input shape,
since that will be empty. Draw a box with rounded corners irectly
instead, in fully opaque black.
https://bugzilla.gnome.org/show_bug.cgi?id=759905
Otherwise the gtk_grab_remove() calls on widget destruction will happen
on the default window group, which may leave the real window group
of the popover with a dangling pointer if it is not the default one.
This could be seen on the inspector, open a popover in the properties
list and close the window with alt-F4.
Under X11, popovers are always constrained to the toplevel
window. Under Wayland, they aren't. This commit adds a
property that allows to explicitly constrain popovers to
the toplevel, giving them the same behavior under Wayland
as under X11.
https://bugzilla.gnome.org/show_bug.cgi?id=757474
Call gtk_popover_update_position instead which will pick up the new
transition_diff value and pass it on to
_gtk_window_set_popover_position, which in turn will move the window
correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=755435
These days exposure happens only on the native windows (generally the
toplevel window) and is propagated down recursively. The expose event
is only useful for backwards compat, and in fact, for double buffered
widgets we totally ignore the event (and non-double buffering breaks
on wayland).
So, by not setting the mask we avoid emitting these events and then
later ignoring them.
We still keep it on eventbox, fixed and layout as these are used
in weird ways that want backwards compat.
Instead, inherit style from toplevel (because that's the default way,
not because it makes lots of sense).
This way, popovers don't inherit the styling from the widget that popped
them up, which is a problem in selected listbox rows, selection-mode
headerbars.
It also doesn't inherit styling where we might want it, like the osd.
But we can only have one of the two things.
This behavior has been made optional on add_popover() time, text handles
will keep being able to overflow the window, in order to allow text
selection on views too close to the window edge.
Regular GtkPopovers are reinstaurated to the previous size positioning
logic though, that is, limited by the visible area of the window.
This will be the widget that the popover relates to (::pointing-to in
GtkPopover, ::parent in GtkTextHandle).
Additional API to check the popover/parent relationship between widgets
has been added, which will be useful wherever this is necessary in a
generic manner.
https://bugzilla.gnome.org/show_bug.cgi?id=750993
Due to popover modality itself, there's quite high chances the popover
stealing focus has been triggered from within, so stay friendly to it.
Hiding the popover here will only hide the grabbing popover too if this
happens.
https://bugzilla.gnome.org/show_bug.cgi?id=750741
The check used to hide the popover if the pointed area fell partly out of
the widget allocation, textviews now can trigger that with text selections
too close to the visible edge, as a small extra area around is now reserved.
The check has been changed to only hide the popover if the pointed area
falls completely outside the widget allocation.
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
