Make it possible to control libcanberra support so we don't risk ending up with
a cyclic dependency when using packages: gtk+ -> libcanberra-gtk3 -> gtk+
https://bugzilla.gnome.org/show_bug.cgi?id=746904
I managed to stall recent files today while trying to save a GTK
testcase in glade that contained enough spinning spinners that the CPU
was saturated just redrawing things.
I had to navigate the filesystem!
The direction in which the slider moves can be inverted by setting the
inverted property. But the draw method does not check this, instead it
checks if the direction of the widget is set to be right to left.
Call the should_invert function in order to determine if the direction
of the range should be inverted. It too checks the widget's direction,
but also checks the "inverted" property, and allows the range to be
drawn inverted even if it is vertically oriented.
https://bugzilla.gnome.org/show_bug.cgi?id=746712
Compute the proportion of the range that should be filled to match the
fill level, and use it to compute the starting point and length of the
area between the slider and the fill level.
https://bugzilla.gnome.org/show_bug.cgi?id=734741
As it is, GtkListBox model binding will work nicely as long as your
create_widget_func returns a floating reference on the newly-created
widget.
If you try to return a full reference (as any higher-level language
would do) then you will leak that reference.
Fix that up by converting any floating references into full references
and then unconditionally releasing the full reference after adding to
the box.
https://bugzilla.gnome.org/show_bug.cgi?id=746893
If the GLX_EXT_texture_from_pixmap extension is not available when we
did the extensions check, then there's no point in using the backend
specific code paths that rely on it.
Use screen workarea to *also* set the position of a maximized window,
not just its size. Without this the window position defaults to 0:0
(the topleft corner), which is wrong when taskbar is position along the
top or left edge of the screen.
https://bugzilla.gnome.org/show_bug.cgi?id=746821
Clang complains that this check can never be true. Since this
is a argument range check which we do to catch bad input,
convince clang to not complain instead of taking it out.
