Drag-and-drop moving to GDK
- Date: Wed, 20 Jan 2016 15:47:48 +0100
- From: Carlos Garnacho <carlosg@xxxxxxxxx>
- Subject: Drag-and-drop moving to GDK
This is mostly a heads up for the win32/quartz/broadway hackers around.
I recently pushed wip/garnacho/dnd-grab to master, which was meant to
move the source side aspects of drag-and-drop into GDK. As I know
close to nothing about other backends than x11/wayland in this aspect,
I took an incremental approach, this mode of operation is triggered by
gdk_drag_context_manage_dnd(), which is only called in gtk/gtkdnd.c
for x11 and wayland so far.
This "managed" DnD supposes the following changes:
- All input events are entirely consumed entirely within GDK.
gtk/gtkdnd.c no longer sees button, motion, key... events, all their
expected GDK callbacks (gdk_drag_motion(), gdk_drag_abort and
gdk_drag_drop) are entirely handled within GDK now.
GdkDragContext::drop-performed is the only signal now available to
notify of the progress of the physical action (eg. button being
released, enter being pressed, whatnot)
- Likewise, all source side GdkEventDNDs (GDK_DRAG_STATUS,
GDK_DROP_FINISHED) are also consumed within GDK. the
GdkDragContext::dnd-finished signal is the replacement for
GDK_DROP_FINISHED. GdkDragContext::action-changed is the rough
replacement of GDK_DRAG_STATUS. Cursor changes derived from drag
action changes are also meant to be handled by the backend.
- The way keyboard modifiers/etc influence the drag-and-drop
operation, and the resulting action after source-destination
negotiation is made also backend-dependent. Before, the caller was
expected to change the preferred action through gdk_drag_motion(), and
wait for the ACK in a GDK_DRAG_STATUS event. The negotiation of the
action altogether is considered now backend dependent,
GdkDragContext::action-changed events are expected to be emitted as a
I don't know how much of gtk/gtkdnd.c code do those backends actually
run, or how badly taped is the DnD support to specifically make GTK+
DnD work altogether, so I'll let backwards compatibility concerns to
you (eg. face to pure-GDK clients, if any), anyhow I added the
handle_event() GdkDragSource vmethod so that consuming events or not
may be a late choice based on gdk_drag_context_manage_dnd() having
been called or not.
When all backends are ported, we'll be able to remove plenty of dead
code in gtk/gtkdnd.c, would be great to accomplish that someday soon.
If any doubts arise, don't hesitate to ask.
gtk-devel-list mailing list