Update Arabic translation
Ensure that print operation is alive until we're done

https://bugzilla.gnome.org/show_bug.cgi?id=733767
GtkWindow: Make set_focus work before show

So far, gtk_window_set_focus just did not work when called on
a hidden window. Change it to record the desired focus widget
for hidden windows, and apply it when the window gets shown.

This is similar to how we tread other window properties that
can't be set before the window is realized, like maximized
or fullscreen.

This is related to
https://bugzilla.gnome.org/show_bug.cgi?id=734033
Add a test for window focus handling

This is a small test that checks that gtk_window_set/get_focus
behave as expected, regardless of the window being shown or hidden.
GtkWindow: Add a way to declare initial focus in ui files

With this commit, it is possible to use <initial-focus name="blah">
to declare the initial focus widget for a window.

This is related to
https://bugzilla.gnome.org/show_bug.cgi?id=734033
Set initial focus in some dialog tests

Use the new <initial-focus> element here to confirm that it is
parsed properly and works as expected.
icon-browser: Show category descriptions as tooltips

No better place for them right now.
icon-browser: Redo the icon categorization

Instead of slavishly following the naming spec, group the icons
into categories that are more likely to be useful for application
developers. Based on input from Allan Day and Jakup Steiner.
Remove generated gtk-win32.rc from EXTRA_DIST

https://bugzilla.gnome.org/show_bug.cgi?id=733773
W32: Don't unregister parent window of an embedded widget

This leads to an assertion failure, because parent window is never registered
in the first place, widget's own GdkWindow is. But that window is unregistered
in a generic fashion by GtkWidget code, so there's nothing for us to do here.

https://bugzilla.gnome.org/show_bug.cgi?id=733766
Use g_clear_object() shorthand for unref-and-set-to-null

https://bugzilla.gnome.org/show_bug.cgi?id=733766
W32: Don't crash when opacity is set for non-toplevel

X11 backend doesn't, and for good reason - main code body does not check
that the window it sets opacity for is, in fact, toplevel.
Just silently fail to do anything for non-toplevel windows.

https://bugzilla.gnome.org/show_bug.cgi?id=733769
Remove a reference to a non-existing function
GtkActionHelper: add some debugging output

Introduce a new debug category "actions" and write some messages from
GtkActionHelper about if we can find the actions or not.

We will probably soon want to add some similar messages to
GtkMenuTrackerItem.

https://bugzilla.gnome.org/show_bug.cgi?id=733965
GtkMenuTrackerItem: introduce action debugging

Add some action debugging output for GtkMenuTrackerItem as well...

https://bugzilla.gnome.org/show_bug.cgi?id=733965
Add the new debug option to the docs

All debug options are supposed to be listed in the "Running and
Debugging" section of the docs.
gtkcairoblur: Replace our exponential blur with the box blur from mutter

https://bugzilla.gnome.org/show_bug.cgi?id=734053
Small comment fixups

One factual pointed out in the review in
https://bugzilla.gnome.org/show_bug.cgi?id=734053, plus some
formatting nit picks.
gtkcssshadowvalue: Don't double-apply the alpha to shadows

It turns out that when we were painting the shadows, we painted the them
with the base color once, which contained the alpha, and then blurred it
and used it as a mask for the fill, which has the fill again.

To fix this, always paint the base surface with full alpha. The existing
code applies the blur conditionally sometimes in weird ways, so the code
shuffling fix may not look correct, but be assured it is. If the blur
happens, the new cr we return has the *default* color applied, which is
fully opaque black, which works perfectly against the A8 surface.

The fallback spinner code needs some modification, since it is
intentionally using the alpha to paint the lobes which are "in the past".
Since we shouldn't be hitting this fallback path very often, we use a
temporary group and paint it with paint_with_alpha, even though it is
slow.
window: Only avoid queueing resizes if the popover position didn't change

If the same position is requested on a popover, it should at least ensure
the window is realized and raised, even if no resizes are queued on the
content. Otherwise other widgets being mapped might raise the windows over
the popover's if its original position is unchanged.

https://bugzilla.gnome.org/show_bug.cgi?id=734129