The M*TIF toolkit uses a special persistent, input-only, and override-redirected window to store some data needed for the whole drag and drop infrastructure. This special window is a child of the display's default root window and is called the ``M*TIF Drag Window''. In order that clients can find this window at all, they should watch out for the property _MOTIF_DRAG_WINDOW (of type WINDOW, with a size of 32) on their display's default root window. If there's no such property, or the window ID stored in the property is either 0 or invalid, then an client should create the ``M*TIF Drag Window'' itself. The ``M*TIF Drag Window'' should have a close-down mode of RetainPermanent (use XSetCloseDownMode() for this), so other applications don't have to create it themselves.
The ``M*TIF Drag Window'' currently seems to posses three properties named _MOTIF_DRAG_TARGETS (of type _MOTIF_DRAG_TARGETS, size is 8), _MOTIF_DRAG_ATOMS (of type - guess which - _MOTIF_DRAG_ATOMS), and finally _MOTIF_DRAG_ATOM_PAIRS (of course of the type _MOTIF_DRAG_ATOM_PAIRS).
Of primary interest to us is the _MOTIF_DRAG_TARGETS property: it is a list of target lists, which is shared among all clients, and is commonly called the ``targets table''. Every target list within the targets table is a list of target (data types) an initiator can supply to a receiver on request. Remember, that the X client messages only provide precious little space for the client's data. Thus, instead of passing such lists around, you only need to pass a single CARD16 value that acts as an index (0-based) into the list of target lists. By specifying such an index, a receiver knows which kinds of data it can request from the initiator during the drop phase.
Whenever a client needs to add his target list(s) to the targets
table, it must follow some guidelines, otherwise the targets table
could become messed up. Every target list must be sorted into
ascending order (according to the atom ID's) to avoid permutations of
otherwise compatible target lists. Thus, if a client supports the
target types ``B,A,C'' and another client supports the target types
``C,B,A'', then they must both use the sorted target types list
``A,B,C'' instead. Note however that the targets TARGETS and
MULTIPLE - which are mandatory according to the ICCCM - are
never listed. The structure of the targets table is fairly
straightforward and is shown in table ![[*]](cross_ref_motif.gif)
.
_MOTIF_DRAG_TARGETS
|
In order to add its target list(s) to the targets table stored in the _MOTIF_DRAG_TARGETS property, a client must grab the X server, so the operation is atomically. Then it has to search the targets table for a match. Otherwise, the client can add the particular (sorted) target list to the table anywhere (the target table itself is not sorted - sigh). After it has updated the _MOTIF_DRAG_TARGETS property, the client can remove the grab.