nth-child() is 1-indexed, not 0-indexed.
It doesn't matter for this test really, but better do it right to not confuse
poor developers who wonder why the first image is highlighted when nth-child(0)
clearly states "none".
We added code to look for settings.ini in system config dirs,
and then proceeded to move it to /usr/share/gtk-3.0 :-(. So,
look in that location as well.
We now pass NULL when the current color should be the default value of
the "color" property and we haven't looked up any value yet. This way we
don't need to look it up all the time and more importantly we can
resolve the default color, which is required because it's a
GtkCssColorValue and not a GtkCssRgbaValue.
Fixes assertions triggering at Polari startup.
The version of device scale that landed in upstream cairo
master already inherits the device scale in cairo_create_similar,
so no need to do that in gtk anymore.
The reftest is a bit flaky because it compares cell renderers with
GtkImage and therefor an icon view with a GtkBox, but it's the best I
can come up with.
https://bugzilla.gnome.org/show_bug.cgi?id=702423
Even when not following states, blacklist the states we don't follow
instead of whitelisting the ones we do. This way, we don't accidentally
eat new ones like the text direction flags.
Fixes a bug where text direction wasn't available when rendering stock
items.
https://bugzilla.gnome.org/show_bug.cgi?id=702423
Due to the split up of the property sheets, the install projects did not
have info on the Intermediate and Output Paths, which caused confusing
messages from Visual Studio to show up upon completing build+"install" and
closing Visual Studio on whether to reload the install project, at least on
Visual Studio 2008.
Also clean up the Visual Studio 2008 install project a bit.
Include the property sheet which defines these properties to fix this.
In the gnome-ostree model builddir contains all generated files not in
git (unless the build system explicitly overrides that). Here the
wayland-client-protocol.h was in $(builddir)/wayland, so we need to
find it using our already extant -I$(top_builddir)/gdk, rather than
relying on same-directory lookup.
Add the concept of shell capabilities, which allow the compositor
to advertise support for the app menu and the global menubar,
which are then propagated as GdkSettings.
https://bugzilla.gnome.org/show_bug.cgi?id=707129
If the compositor supports the gtk-shell interface, use it to
export the application ID, dbus name and paths that can be used
for the application menu.
https://bugzilla.gnome.org/show_bug.cgi?id=707129
Call gtk_widget_get_mapped() in a couple of places before looking at the
widget's parent, since it might be set to a widget that has been
finalized, causing an invalid read.
