Only if they fall outside the grab widget, in that case the widget holding
the implicit grab won't be receiving events anymore, so we can just undo
it.

It is no longer necessary to receive events, so it's relatively straightforward
now to drop.

We now rely on toplevels receiving and forwarding all the events
the windowing should be able to handle. Event masks are no longer a
way to determine whether an event is deliverable ot a widget.

Events will always be delivered in the three captured/target/bubbled
phases, widgets can now just attach GtkEventControllers and let those
handle the events.

This function will, at the last minute, ensure the event contains the right
widget-relative coordinates for the widget the event is being emitted to.

Those are now needless and wrong, as we get guarantees that handled
events will contain widget-relative coordinates. A side effect is
that these events are very possibly not explicitly sent to the
GdkWindow that implementations expect, any extra checks performed
through gtk_gesture_set_window() will be wrong, so the function has
been dropped entirely.

It's now meaningless since the gesture will receive the event despite
the input only window.

It's now meaningless since the widget will receive the event despite
the input window.

This makes notebooks happy again after changing event coordinates to always come in
the widget coordinate system.

These are now wrong and prevent the code from running correctly.

It is now meaningless and wrong, since GdkWindows aren't used anymore
to determine the event target.

This is no longer set through the Gdkwindow, so use private GtkWidget
API.

And refurbish cursor management to be set on the GtkWidget. The
input window is not needed anymore to receive events either.

This is no longer set through the GdkWindow, so use the private
GtkWidget API.

This should be eventually replaced by CSS cursors, but at the moment
it must be handled on the gtk/ side.

There is now a set_client_widget() to hint the IM about positioning
and whatnot.

The event shall no longer be "directed" to the event window, but the
widget. Getting a enter/leave event is enough now to know whether the
pointer is inside or outside the widget.

Just a basic setter/getter, plus a method to obtain the right logical target
in the presence or absence of these.

Unlike GTK+ grabs which are global to all/one device, the implicit grab
is per focus, which means each may have implicit grabs on different or
the same widget.

As we don't obey GdkWindow cursors anymore, someone must set those.
Use the private Gtkwidget API at the moment.

Those are situations that must cause foci on these widgets to repick
themselves.

Now that gtk_main_do_event() is able to handle pointing events in toplevel
coordinates, forward all of these as is. Just minimal handling is still done
on the gdk side for GDK grab accounting, and toplevel tracking for each
pointer.

Implement target finding per-pointer/touchpoint through GtkPointerFocus and
_gtk_toplevel_pick(). Focus changes are handled through the emission of
crossing events between the old target and the new one.

Each toplevel will keep its own tracking of the current ongoing foci,
add the plumbing that will allow to create/update/remove those as they
come and go.

These objects (tied to a toplevel) track the focus of a pointer/touchpoint.
The info in these basically consists of current toplevel coordinates and the
current target widget.

This function will be useful in other places, such as determining the
widgets that must receive crossing events after pointer picking points
to another widget.

A helper function basically for gtk+, so coordinates can be translated
in place depending on the widget it's being delivered to.

This function returns both the widget at the given toplevel coordinates,
and the translated x/y in widget relative coordinates.

The default implementation iterates through all children, so should suffice
for most widgets.

A little helper function for a somewhat common operation.

Aborting the application makes it look like an application bug, when
it is the expected thing to do when the Wayland display server goes
way. eg., when the user logs out. The log level is also demoted to
avoid a storm of warnings in the log from all applications whenever
this happens.

This is also what the X11 backend does (see gdk_x_io_error).

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

gtk-doc behavior changed, it seems, and these options now
cause the build to break.

The :last-child selector supposed to reset the border was
overridden by the :hover selector. This is fixed by moving the
:last-child selector after the overriding one.
Thanks to Sebastian Keller for spotting.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=779078.

https://bugzilla.gnome.org/show_bug.cgi?id=779653#c33
and this is closer to what gtk-3-22 says anyway.

The rest of the ui file follows that convention.

commit 5729ea77 skipped these

…erties clobbered by commit c92b7d42.
That and its counterpart were for removing :expand and :fill child props
from GtkBox, but they ended up catching these for GtkToolItemGroup too.

While GtkToolItemGroup still has these, we may as well keep demoing them