Keywords: LessTif

Next: 5. Advertising a Receiver Up: 2. Protocol Basics Previous: 3. Drag & Drop Contents Index

## 4. The Targets Table

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 .

_MOTIF_DRAG_TARGETS

Table: Structure of the targets table in the property _MOTIF_DRAG_TARGETS.
Offset | Size | Description
+0x00 | BYTE | Byte Order: either 'B' (MSB first) or 'l' (LSB first).
+0x01 | BYTE | Protocol Version: currently 0.
+0x02 | CARD16 | Number of Target Lists: this should be really self-explanatory.
+0x04 | CARD32 | Data Size: total size of the data stored in the property:
|  | 8 bytes for the header +
|  | Number of Target Lists * 2 +
|  | Total Number of Targets * 4
+0x08 | CARD16 | Number of Targets in List
+0x0A | CARD32 | List of Targets
+0x?? | CARD16 | Number of Targets in List
+0x?? | CARD32 | List of Targets
|  | ...and so on...

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.

Next: 5. Advertising a Receiver Up: 2. Protocol Basics Previous: 3. Drag & Drop Contents Index