This implementation makes the destination side of selections work
similarly to X11's, gdk_selection_convert() triggers data fetching,
which is notified through GDK_SELECTION_NOTIFY events on arrival,
the buffered data is then available through gdk_selection_property_get().
https://bugzilla.gnome.org/show_bug.cgi?id=697855
All the globals we care about should appear before doing anything
else, up-front, so a single round-trip after adding the registry
should be more than enough.
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.
If we bind to a global with an higher version than implemented, or
we make requests that appeared in a later version, we would get
fatal wayland errors.
https://bugzilla.gnome.org/show_bug.cgi?id=704104
We use a ref-count mechanism to track whether parts of the init sequence
still needs round trips to receive remaining initial state. Typically
we need a couple of roundtrips total to get the global list, then the
input and output configurations, but with the ref-count we avoid making
global assumptions like that.
https://bugzilla.gnome.org/show_bug.cgi?id=696340
This requires the SHM object be initialised - therefore this is the most
logical (if slightly ugly place.)
We also need to make sure that we do something clever to load the correct
cursor theme.
The data device manager is a global object that provides the support
infrastructure around data devices. These data device objects are the basis
for handling drag and drop as well as selections in Wayland.