Removing pages from the assistant with gtk_widget_destroy() used
to work. It broke with the recent interposition of a box between
each page and the notebook. Fix this by cleaning up when the box
child is removed.
https://bugzilla.gnome.org/show_bug.cgi?id=756042
In fact there were two issues:
1. GtkFlowBoxChild with "can-focus"==FALSE should pass the focus
to its child immediately.
2. GtkFlowBox with "can-focus"==FALSE should cease its custom keynav
implementation and fall back to the default GtkContainer behavior
which is more natural.
Thanks to these changes the flow box can act as a better replacement
for GtkGrid and similar containers.
https://bugzilla.gnome.org/show_bug.cgi?id=753371
Replace checking if the NSView is really a GdkWindow, which will crash
in the likely event it's not a GObject, with ensuring that the parent
GdkWindow is really a GdkWindowQuartz.
Move focus to list when search results appear to make it
possible to select the first search result by just hitting
Enter. To keep this from interfering with keynav, we need
to make sure that we still handle Escape to search. And when
search comes up empty, we need to move the focus back to the
entry.
https://bugzilla.gnome.org/show_bug.cgi?id=755926
The stack calls gtk_widget_grab_focus on the last focus widget,
which selects the text in the entry, so we need to make sure to
move the focus there first to keep that from happening.
https://bugzilla.gnome.org/show_bug.cgi?id=755931
Once a window is maximized/fullscreen, resize increments should be
ignored otherwise the window may appear smaller than the screen size.
That also applies to configure requests as well.
https://bugzilla.gnome.org/show_bug.cgi?id=751368
We were calling gtk_container_should_propagate_draw
twice for each child. We can avoid this by splitting
out an gtk_container_propagate_draw_internal function.
Almost all callers of _gtk_widget_draw already did their own
cairo_save/restore, so drop the save/restore calls inside
_gtk_widget_draw and instead fix the last caller, gtk_widget_draw,
to do the same.
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
Check whether the given popover even changed size in
_gtk_window_set_popover_position. If not, just move its GdkWindow
without calling gtk_widget_queue_resize. Using popover_get_rect here is
still relatively costly, but popover_size_allocate would be doing that
anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=755435
