This was another complication that we had to have to support the
split between libwayland-server and weston. Different grabs want to send
events relative to different surfaces at different times. The default
grab switches between sending coordinates relative to the 'current' surface,
that is the surface the pointer is currently above, or the 'clicked'
surface, in case of an implicit grab.
The grab focus was set by the grab implementation and the core input code
would transform the pointer position to surface relative coordinates for the
grab focus and store in grab->x/y.
Now we can just let the grab implementation transform the pointer
coordinates itself, leaving the implementation free to transform
according to whichever surface it wants. Or not transform at all if
it doesn't need surface relative coordinates (like the shell move and resize
grabs).
device_setup_new_drag_surface() and device_release_drag_surface() are both
now fairly small and only called from data_device_start_drag() and
data_device_end_grab() respectively. Folding the two functions in where
they're called from simplifies the code flow a bit.
struct weston_surface is now the only surface type we have (in core, shell.c
has shell_surface, of course). A lot of code gets simpler and we never
have to try to guess whether an API takes a wl_surface or a weston_surface.
We can now update the drag icon position directly from the configure
handler or the grab motion handler, and no longer need
weston_seat_update_drag_surface().
Previously we just got the drag_icon signal and had to figure out what
changed. Now we can directly setup or release the drag icon when the
drag starts and stops.
We have to deal with the data source going away. Even if we have a
reference to the server side data source, we can't do anything if the
client that provided the source went away. So just NULL the offers
source pointer in the destroy callback for the source.
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.