quartz: Add missing g_object_ref

See merge request !768

A g_object_ref() call was missing, sometimes causing crashes during
drag-and-drop operations. The matching g_object_unref() is at
gdk/gdkdnd.c:261.

The logic in this function is still wrong--it finds the wrong GdkWindow under
some circumstances--but this commit fixes the crash.

Part of #1840.

gdk/wayland: Listen to wl_surface events on tablet cursors

See merge request !759

And update the surface accordingly (eg. scale on hidpi). The mechanism
that did that for wl_pointer has been made generic so it can be shared
with tablets too.

Closes: #1675

wayland: Avoid using uninitialized memory

See merge request !758

_gdk_wayland_cursor_get_buffer was not initializing
its out variables in the 'not found' case. This
was showing up in protocol traces as garbage hotspots
being sent to the compositor.

Closes: #1328

Avoid an "implicit declaration of ..." warning/error for using
close()/write().

Update the years to 2019, and use some better typography.

Just because we can.

Backport from master: f9a5a474

gdk/wayland: Use event window to calculate coordinatess for show_window_menu()

See merge request !749

The previously used window always was the xdg_toplevel window.

This resulted in -DINCLUDE_IM_ti-et getting passed to gcc resulting in
lots of warnings. Use underscorify() so we get the correct -DINCLUDE_IM_ti_et instead.

meson: Fix build on macOS

See merge request !735

Don't hardcode things, and move only deduce `current` for non-Visual
Studio builds, as it is only used there.

Previously, Meson failed to run on macOS. This was because a value that should
have been an array of strings was instead a single string.

Commits a04fef4b and cc7f9c44 inadvertedly broke Visual Studio builds as
it caused the following to show up when configuring:

gdk\meson.build:281:0: ERROR: Invalid Shared library version "vs9.2404.4". Must be of the form X.Y.Z where all three are numbers. Y and Z are optional.

Since we do not set a library version that mingles with the minor and
micro versions, along with libtool current for any Visual Studio builds,
just set those versions as 3 on Visual Studio builds, and things should
work the way they did before.

See a04fef4b

GTK 3.24.8 was just released.

The Meson build is missing the libtool versioning of the shared
libraries.

Since commit 3b2f9395, the frame time may be set into the future, so
only ensure monotonicity, and don't store the offset. This prevents the
frame time from becoming out of sync with g_get_monotonic_time().

Fixes #1612

GTK 3 meson port

See merge request !716

Those symbols need to be properly exported for Visual Studio builds for
things to work properly.  Fixes the test on Visual Studio builds.

This adds a set of instructions, notes and known issues for the
Meson builds on Windows, especially Visual Studio.

We also need to ensure that we pass in -DINCLUDE_IM_xxxx when building
the GTK DLL/.so, in addition to building the respective (static)
immodules, so that we did really link in the immodules into the final
GTK DLL/.so.

This ensures that current Visual Studio project files and NMake
Makefiles (which do not use pkg-config files) do not break with the
Meson-built GTK-3.x libraries.

Make it a yes/no/auto combo. "yes" means all modules are built into libgtk,
"no" that none are and "auto" uses the platform defaults, yes on win32,
no otherwise.

If we need more we can always extend it later.

This makes the DLL names match those that are produced by the Visual
Studio projects by default.

This, currently, however, names the .lib files same as the ones that
are produced for other platforms (i.e. <libname>-3.lib).  This is
actually not that bad as one can just copy those .lib's into
<libname>-3.0.lib when needed and the binaries that link to those .lib's
ultimately link to the same DLLs, so this should not harm binary
compatibility.

It may be so that Cairo is not found using pkg-config files, so we
cannot just use .name() on the Cairo deps directly.

Since we already have a similar mechanism for generating the GDK .pc
files, re-use and share that mechanism.

It seems that Meson 0.50.0 broke dependency search using CMake for
HarfBuzz at least, so we add a workaround for it to look for the
HarfBuzz headers and libraries manually when we couldn't find HarfBuzz
using the pkg-config and CMake method.

This should result in <libname>-vs<VSVer>.dll filenames.

Various adjustments to make the config.h output between autotools
and meson more similar by testing on Linux and Windows/MSYS2.

Setting things to 1 instead of true and shifting things around is motivated
by reducing the diff between the generated files.

See #33