4. The Drop Protocol

The drop protocol can be used independently of the drag protocol, for example when a drop site is in the XmDRAG_DROP_ONLY mode. Fortunately, the whole drop protocol is really lean - it just consists of the single message XmDROP_START sent by the initiator, which must be echoed by the receiver.

Table: The XmDROP_START message send by the initiator.

Message User Data	Size	Description
data.b[0]	BYTE	Reason: XmDROP_START (0x05)
data.b[1]	BYTE	Byte Order: either 'B' (MSB first) or 'l' (LSB first).
data.b[2..3]	CARD16	DnD Flags: 1 + 3
data.b[4..7]	CARD32	Timestamp: set to the timestamp of the corresponding X event triggering this message.
data.b[8..9]	CARD16	Root X: x position relative to the root window.
data.b[10..11]	CARD16	Root Y: y position relative to the root window.
data.b[12..15]	CARD32	Drag Initiator Info Atom: atom ID of a property the initiator set up when it started the drag (or drop, if we're in XmDRAG_DROP_ONLY mode).
data.b[16..19]	CARD32	Source Window: source window ID of the initiator.

The receiver then echoes this XmDROP_START message, indicating whether it is willing to accept the drop and what operation (move, copy or link) it want to carry out.

Table: The XmDROP_START message echoed by the receiver.

Message User Data	Size	Description
data.b[0]	BYTE	Reason: XmDROP_START (0x85)
data.b[1]	BYTE	Byte Order: either 'B' (MSB first) or 'l' (LSB first).
data.b[2..3]	CARD16	DnD Flags: 1 + 2 + 3 + 4
data.b[4..5]	CARD16	Better X: better x position (hint for the initiator) of the drag-over icon relative to the root window.
data.b[6..7]	CARD16	Better Y: better y position (hint for the initiator) of the drag-over icon relative to the root window.

If the receiver did not cancel the drop (which it must indidicate within the echoed message), then it can proceed to transfer the drop data using the X selection transfer mechanism. The receiver can request as many transfers as it wants, using the selected targets. For each conversion request, the initiator replies using the ICCCM selection.

XmTRANSFER_SUCCESSXmTRANSFER_FAILURThe resources allocated during the drag operation should not be released until the drop is finished. The receiver indicates this by requesting a conversion for the targets XmTRANSFER_SUCCESS or XmTRANSFER_FAILURE. When the initiator receives such a conversion request, then it must reply with an empty value.The receiver as well as the initiator can then release all resources allocated for the drop operation. In addition, it's the right time to show the melting or failure/snapback visual effect.