Before, gtk_drag_icon_new_for_drag() allowed creating new drag icons.
This could cause multiple drag icons to exist for a single drag.
Now, gtk_drag_icon_get_for_drag() makes sure that only one drag icon is
created.
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.
Most users were just forgetting to set the proper flags.
And flags aren't the right way to set this anyway, it was just
acceptable as a workaround during GTK3 to not break API.
Make it return the content provider to use for
the next drag. This allows just-in-time provision
of the content provider. The default handler just
returns the value of the ::content property.
Remove arguments from the constructor.
For actions, we now default to COPY, which is the most common one
that we should enable by default (MOVE requires handling deletion
on the the source side, and ASK only makes sense if we have
multiple actions).
For the content provider, we add a new ::prepare signal where
it should be provided just-in-time.
Add an explicit GtkDropTarget object, and move the destination-side
DND signals here. The object is used by connecting to its signals
and attaching it to a widget with gtk_drop_target_attach().
Add an explicit GtkDragSource object, and move the source-side
DND signals here. The object can be used on the spot, by calling
gtk_drag_source_drag_begin() yourself, or for static drag-source
configuration, by calling gtk_drag_source_attach(). In the latter
case, we set up and conect a drag gesture to trigger the drag_begin
call.
Remove all the old 2.x and 3.x version annotations.
GTK+ 4 is a new start, and from the perspective of a
GTK+ 4 developer all these APIs have been around since
the beginning.
Instead of allowing people to pass a uint user-data, insist on them
comparing mime types.
The user data was a uint instead of a pointer anyway, so uniqueness
could not be guaranteed and it caused more issues than it was worth.
And that's ignoring the fact that it basically wasn't used.
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.
