Just to show that this is essentially the same as GdNotification
already.

This hideous hack is necessary so far because the main users of
GtkScaleButton are also clutter users, so the GtkScaleButton popover
will be very likely shaped against a clutter-enabled native window.

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

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

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

When creating windows, and when returning a widgets
visual, use the new API to get the preferred visual.

Unless GDK_RGBA=0 is set, this will be the RGBA visual.
The new function is called gdk_screen_get_preferred_visual().

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

This reverts commit a2ccb660.

This turns out to break GtkStatusIcon, and invalidates
the documentation of gdk_screen_get_system_visual().

Try this again, this time being a bit more careful about size
allocation of titlebars.

This reverts commit 54ec1575.

This did the reverse of what it should, making the shape be
the part where the children were *not*.

Since realize does a lot of the heavy lifting of setting up
csd, we have to re-realize the window if we go from no-custom
titlebar to a custom titlebar or vice versa.

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

When gtk_window_set_titlebar is called, we need to set up
client-side decorations properly, and the easiest way to do
so is to realize the window again. Really, you should call
set_titlebar before the window is realized.

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

10b5ec20

 made sure not to set focus_child to NULL all the way up to the
top, but only up to the common ancestor. However, it would never set it
on the common ancestor itself, which would therefore remain with a
focus_child set when it shouldn't.

A manifestation of the bug: focus column headers of a treeview, press Tab.
Now pressing Shift+Tab will go to another widget and not the column
headers, and Tab will (appear to) do nothing, all because the treeview
still has a focus_child set to column headers after a grab_focus().

Signed-off-by: Olivier Brunel <jjk@jjacky.com>

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

Based on a patch by Eugene Shatokhin,
https://bugzilla.gnome.org/show_bug.cgi?id=723366

This commit uses the Xlib cache to obtain the name of the X extension
for the request that caused the error.

https://bugzilla.gnome.org/review?bug=723555

We can't destroy buffers if they're in-use by the compositor. Well,
technically we can, but that is considered undefined by Wayland and
mutter won't cope with it very well -- it simply kills the client.

To solve this, we need to delay the destroy operation until the
compositor tells us that it's released the buffer. To do this, hold
an extra ref on the cairo surface as long as the surface is in-use
by the compositor.