wip/carlosg/event-delivery

[Carlos Garnacho <carlosg gnome org>]

Hey hey,

After some accidented post-hackfest, here's at last some work towards
removing event masks and input only windows.

https://git.gnome.org//browse/gtk+/log/?h=wip/carlosg/event-delivery

The usual random bunch of thoughts/notes/caveats:

- All picking and crossing event generation happens on the gtk+ side.
There's some remnants in gdk regarding windowing grab handling (which
must remain on toplevels), but most of gdk_windowing_got_event() could
be trimmed already.

- Coordinates are now transformed to widget-relative coordinates while
emitting the capture/target/bubble phase instances. This means that 1)
GtkGesture doesn't do it internally any longer, and 2) widgets doing
manual event handling on windows that don't match the widget size will
 get it wrong.

- As events are now delivered on all widgets between the target and
the toplevel regardless of GdkWindows, event->any.window has become
kinda pointless (except for conveying the toplevel where the event
happens) and all checks on it are wrong. The question of which data
type/api is better to convey a widget on events remains (still
important I guess for event->crossing.subwindow).

- Thinking a bit further about crossing events, I actually wonder if
we need them that much in the future, most widgets just update css
hover/prelight state, and that should probably happen automatically.

- Probably a good next step is making GdkEvent struct hidden and only
accessible through API, and this API should be probably private to
GDK/GTK, although that opens some more cans of worms (eg. ::event
signals in cell renderers/textview tags/etc)

- GtkWidget event masks are no more. Widgets are already able to
receive events without ever setting one, This makes
gtk_gesture_*_new() the recommended way to actually do anything
related to events. This also makes having GtkEventControllers for key
handling and other missing things more important.

- Likewise, input-only windows are not needed anymore. Only GtkButton
has been made to work without one at the moment, but there's actually
lots of input-only windows that can now be removed all over the place.

- Since cursors are no longer GdkWindow-based, I added some
scaffolding to have the GTK+ part update the cursor during picking. I
also added some private GtkWidget API to set cursors, but I expect it
to be gone when the css bits can provide one. I also made cursor
picking work from bottom to top, dunno what does css say about that.

I hope it sets things in the direction we all expected!

Cheers,
  Carlos