This gesture handles drags done with any button, so unset the current button=1
default.

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

GtkGestureSingle::button is set to 0 on the multipress gesture, as several
buttons are managed by that gesture. Also avoid some extra lines of code
setting what nowadays are default values.

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

GtkGestureSingle::button is set to 0, as multiple buttons are managed by
the same gesture. Also avoid some extra lines of code setting what nowadays
are default values.

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

This now defaults to sane values on mice, so touch-only is set to FALSE,
and button is set to GDK_BUTTON_PRIMARY;

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

This used to rely on the default value, which has changed to a saner default.

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

This used to rely on the default phase value.

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

This is in practice the most common value, so make that the default

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

pwd.h is not used anywhere in GTK+, so no need to check
for it.

Nothing is using gdk-pixbuf-csource anymore, so no need
to set up the GDK_PIXBUF_CSOURCE variable.

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

We need to use gio/gunixsocketaddress.h and do so
only if HAVE_GIO_UNIX is defined.

At the present time broadway listens only for TCP/IP incoming
display connections. This patch implements the support for listening
on unix domain sockets too, adding the broadway_server_on_unix_socket_new()
constructor and the commandline option --unixsocket [path] to broadwayd.

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

gcc was unhappy again.

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

gtk_statusbar_remove_all() was popping the top message if its
context_id matched before removing other matching messages from the
stack. This meant that if the context_id of the second top message
matched it was still displayed when the top message was popped and
then removed from the list of messages without updating the display.
Fix this by removing all the matching messages below the top one
before popping it if it matches.

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

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

&-ing together all the device event types yields zero,
which is clearly not the intention here. Use | instead,
to create the intended mask.

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

These tests check some of the changes from the previous commits.

A spin button really needs an adjustment to work. So don't let the
user unset the adjustment by passing NULL to
gtk_spin_button_set_adjustment.

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

Changing adjustment via the property setter would not emit
value-changed, however changing it via gtk_spin_button_configure would.

This inconsistency had the following side-effects:

  - Setting an adjustment with a different value would not update the
    value shown by the spin button.

  - Creating a spin button like this (common in GtkBuilder XML) will
    not show the initial value:
      g_object_new (GTK_TYPE_SPIN_BUTTON, "adjustment", adj, NULL);

Let's use the same code path (ie. gtk_spin_button_configure) for all
public facing API for setting adjustment. The code that handled the
details of swapping out the old adjustment with the new has been split
into an unset_adjustment method and the rest has been folded into
gtk_spin_button_configure.

A spin button really needs an adjustment to work, so we don't need
most of the NULL checks. However we do need to check in
unset_adjustment because setting a new adjustment during object
creation might try to unset a non-existent one.

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

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

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

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

This is a bad idea in general, but it also means that the focus for a
window drops when we pop up a menu, since the grab transfer menu exists.

As a noinst_PROGRAMS, the libtool generated for cross-compiling will be
used, which will mess up the linking. Create a all-local target instead.
Also ensure that building uses always a native version of the tool by
specifying a GTK_UPDATE_ICON_CACHE automake variable.
Finally "config.h" has been created to work for the target platform and
causes problem when cross-compiling. So we temporarily generate a basic
config.h which contains only the strict minimum.

It is actually a bad idea to use noinst_PROGRAMS for build tools,
because it adds a $(EXEEXT). It is best to override the all target
with all-local to trigger the tool build.

Based on a patch by Yosef Or Boczko,
https://bugzilla.gnome.org/show_bug.cgi?id=731443

instead of using background-image

Previously, we always returned the state flags of the original widget
and did not consider the siblings' pseudoclasses.

Testcase is attached.

Print pseudo-classes using ':' sign.

The theme will be changed to provide padding.