We are passing the event to the tooltip handle_event
function at the very end. Unfortunately, the target_widget
may have already died at that point. We prevent that
by taking a ref during propagage_event, but the tooltip
code was outside of that. Keep a ref until the very
end ot prevent crashes.
Let keyboard/pointer paths handle their own events, and find the
current focus. The event will be propagated through instead of
being just emitted on the toplevel.
This makes it handled throughout all the gestures that want to
know about it.
GdkEvent has been a "I-can't-believe-this-is-not-OOP" type for ages,
using a union of sub-types. This has always been problematic when it
comes to implementing accessor functions: either you get generic API
that takes a GdkEvent and uses a massive switch() to determine which
event types have the data you're looking for; or you create namespaced
accessors, but break language bindings horribly, as boxed types cannot
have derived types.
The recent conversion of GskRenderNode (which had similar issues) to
GTypeInstance, and the fact that GdkEvent is now a completely opaque
type, provide us with the chance of moving GdkEvent to GTypeInstance,
and have sub-types for GdkEvent.
The change from boxed type to GTypeInstance is pretty small, all things
considered, but ends up cascading to a larger commit, as we still have
backends and code in GTK trying to access GdkEvent structures directly.
Additionally, the naming of the public getter functions requires
renaming all the data structures to conform to the namespace/type-name
pattern.
Stop rewriting key and focus events on the GDK side.
Instead deliver them as they are, and propagate them
from the root on the gtk side, in gtkmain.c. And
stop complaining about focus events on popups - we
can just ignore them if we have no use for them.
We have event controller apis to replace these.
There is one remaining use of gtk_get_current_event_time
in gtkwindow.c, so we can't drop the implementation yet.
Add a section in the migration guide for this.
Language bindings—especially ones based on introspection—cannot deal
with custom type hiearchies. Luckily for us, GType has a derivable type
with low overhead: GTypeInstance.
By turning GskRenderNode into a GTypeInstance, and creating derived
types for each class of node, we can provide an introspectable API to
our non-C API consumers, with no functional change to the C API itself.
We were not properly setting the new_descendent field
in Crossing structs for GTK_CROSSING_OUT events. This
was causing extraneous ::leave signals to be emitted,
and make model buttons in popover menus flicker when
hovered.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2536
Under grabbing circumstances we used to get several crossing events,
some corresponding to the grab itself and some corresponding to
pointer motion.
The backends now do a better job at keeping those simple, which
means we sit listening for events that don't actually arrive. This
triggers pointer focus issues when dragging windows or opening
grabbing popups.
Actually obey those events, they will be the only ones we get now.
This is a huge reorganization of GtkDropTarget. I did not know how to
split this up, so it's unfortunately all one commit.
Highlights:
- Split GtkDropTarget into GtkDropTarget and GtkDropTargetAsync
GtkDropTarget is the simple one that only works with GTypes and offers
a synchronous interface.
GtkDropTargetAsync retains the full old functionality and allows
handling mime types.
- Drop events are handled differently
Instead of picking a single drop target and sending all DND events to
it, every event is sent to every drop target. The first one to handle
the event gets to call gdk_drop_status(), further handlers do not
interact with the GdkDrop.
Of course, for the ultimate GDK_DROP_STARTING event, only the first
one to accept the drop gets to handle it.
This allows stacking DND event controllers that aren't necessarily
interested in handling the event or that might decide later to drop
it.
- Port all widgets to either of those
Both have a somewhat changed API due to the new event handling.
For the ones who should use the sync version, lots of cleanup was
involved to operate on a sync API.
Emit crossing events - with a new GTK_CROSSING_DROP type - like we do
for motion events. There is no more special casing for them.
Note that the gesture has not been updated yet, so some obscure behavior
may occur.
Restructure the getters for event fields to
be more targeted at particular event types.
Update all callers, and replace all direct
event struct access with getters.
As a side-effect, this drops some unused getters.
