XmDisplay - The Display widget class
The XmDisplay object is used by the Motif widgets to store information that is specific to a display. It also allows the toolkit to access certain information on widget hierarchies that would otherwise be unavailable. Each client has one XmDisplay object for each display it accesses.
An XmDisplay object is automatically created when the application creates the first shell on a display (usually accomplished by a call to XtAppInitialize or XtAppCreateShell). It is not necessary to create an XmDisplay object by any other means. An application can use the function XmGetXmDisplay to obtain the widget ID of the XmDisplay object for a given display.
An application cannot supply initial values for XmDisplay resources as arguments to a call to any function that creates widgets. The application or user can supply initial values in a resource file. After creating the first shell on the display, the application can use XmGetXmDisplay to obtain the widget ID of the XmDisplay object and then call XtSetValues to set the XmDisplay resources.
XmDisplay resources specify the drag protocol style for a client participating
in drag and drop transactions. There are two basic protocol types, preregister
and dynamic. When a preregister protocol is used, the toolkit handles any
communication between the initiator and receiver clients, and displays the
appropriate drag-over and drag-under visual effects. A client registers its
drop sites in advance and this information is stored in a property for each
top-level window. When the drag pointer enters a top level window, the drop
site information is read by the initiator. A dynamic protocol allows the
source and destination clients to dynamically communicate drag and drop state
information between each other, and to update their respective visuals accordingly.
The toolkit provides drop site information as the pointer passes over any
given drop site. In this mode, a receiver can supply a procedure to generate
its own drag-under effects.
Display inherits behavior and resources from Core, Composite, Shell, WMShell, VendorShell, TopLevelShell, and ApplicationShell classes.
The class pointer is xmDisplayClass.
The class name is XmDisplay.
The following table defines a set of widget resources used by the programmer to specify data. The programmer can also set the resource values for the inherited classes to set attributes for this widget. To reference a resource by name or by class in an .Xdefaults file, remove the XmN or XmC prefix and use the remaining letters. To specify one of the defined values for a resource in an .Xdefaults file, remove the Xm prefix and use the remaining letters (in either lowercase or uppercase, but include any underscores between words). The codes in the access column indicate if the given resource can be set at creation time (C), set by using XtSetValues (S), retrieved by using XtGetValues (G), or is not applicable (N/A).
XmDisplay Resource Set
Class: DefaultVirtualBindings Default: dynamic Type: String Access: CG Class: XmCDragInitiatorProtocolStyle Default: XmDRAG_PREFER_RECEIVER Type: unsigned char Access: CG Class: XmCDragReceiverProtocolStyle Default: XmDRAG_PREFER_PREREGISTER Type: unsigned char Access: CG
The actual protocol used between an initiator and a receiver is based on the protocol style of the receiver and initiator. The decision matrix is as follows:
| Drag Initiator | Drag Receiver Protocol Style Protocol Style | ---------------|---------------------------------------
| Pre Prefer Pre Prefer Dyn Dyn ---------------|---------------------------------------
Pre | Pre Pre Pre D-O
Prefer Pre | Pre Pre Pre Dyn
Prefer Rec | Pre Pre Dyn Dyn
Prefer Dyn | Pre Dyn Dyn Dyn
Dyn | D-O Dyn Dyn Dyn _______________|_______________________________________
Pre = Preregister
Dyn = Dynamic
D-P = Drop Only
The value XmDRAG_NONE does not appear in the above
matrix. When specified for either the initiator or receiver side, XmDRAG_NONE implies that drag and drop transactions are not supported.
A value of XmDRAG_DROP_ONLY (Drop Only) results when an
initiator and receiver cannot compromise protocol styles, that is, one client
requires dynamic mode while the other can only support preregister mode, or
if either explicitly has specified XmDRAG_DROP_ONLY.
All of the superclass resources inherited by XmDisplay are designated
N/A (not applicable).
ApplicationShell(3X), Composite(3X), Core(3X), TopLevelShell(3X), VendorShell(3X), WMShell(3X), XmGetXmDisplay(3X), XmScreen(3X)