Page: 1 2 3 4 5 6 7 8 9 10 11 12 13
14 15 16 17 18 19 20 21 22 23 24 25 26

Chapter 10


Events

A client application communicates with the X server through the connection you establish with the XOpenDisplay function. A client application sends requests to the X server over this connection. These requests are made by the Xlib functions that are called in the client application. Many Xlib functions cause the X server to generate events, and the user's typing or moving the pointer can generate events asynchronously. The X server returns events to the client on the same connection.

This chapter discusses the following topics associated with events:

Functions for handling events are dealt with in the next chapter.

10.1. Event Types

An event is data generated asynchronously by the X server as a result of some device activity or as side effects of a request sent by an Xlib function. Device-related events propagate from the source window to ancestor windows until some client application has selected that event type or until the event is explicitly discarded. The X server generally sends an event to a client application only if the client has specifically asked to be informed of that event type, typically by setting the event-mask attribute of the window. The mask can also be set when you create a window or by changing the window's event-mask. You can also mask out events that would propagate to ancestor windows by manipulating the do-not-propagate mask of the window's attributes. However, MappingNotify events are always sent to all clients.

An event type describes a specific event generated by the X server. For each event type, a corresponding constant name is defined in <X11/X.h>, which is used when referring to an event type. The following table lists the event category and its associated event type or types. The processing associated with these events is discussed in section 10.5.

Event Category Event Type
Keyboard events KeyPress, KeyRelease
Pointer events ButtonPress, ButtonRelease, MotionNotify
Window crossing events EnterNotify, LeaveNotify
Input focus events Focusln, FocusOut
Keymap state notification event KeymapNotify
Exposure events Expose, GraphicsExpose, NoExpose
Structure control events CirculateRequest, ConfigureRequest, MapRequest, Resize Request
Window state notification events CirculateNotify, ConfigureNotify, CreateNotify, DestroyNotify, GravityNotify, MapNotify, MappingNotify, ReparentNotify, UnmapNotify, VisibilityNotify
Colormap state notification event ColormapNotify
Client communication events ClientMessage, PropertyNotify, SelectionClear, SelectionNotify, SelectionRequest

Home


10.2. Event Structures

For each event type, a corresponding structure is declared in <X11/Xlib.h>. All the event structures have the following common members:

typedef struct {
int type
unsigned long serial;
Bool send_event;
Display *display;
Window window;

/* # of last request processed by server */
/* true if this came from a SendEvent request */
/* Display the event was read from */
} XAnyEvent;

The type member is set to the event type constant name that uniquely identifies it. For example, when the X server reports a GraphicsExpose event to a client application, it sends an XGraphicsExposeEvent structure with the type member set to GraphicsExpose. The display member is set to a pointer to the display the event was read on. The send_event member is set to True if the event came from a SendEvent protocol request. The serial member is set from the serial number reported in the protocol but expanded from the 16-bit least-significant bits to a full 32-bit value. The window member is set to the window that is most useful to toolkit dispatchers.

The X server can send events at any time in the input stream. Xlib stores any events received while waiting for a reply in an event queue for later use. Xlib also provides functions that allow you to check events in the event queue (see section 11.3).

In addition to the individual structures declared for each event type, the XEvent structure is a union of the individual structures declared for each event type. Depending on the type, you should access members of each event by using the XEvent union.

typedef union _XEvent {
int type;
XAnyEvent xany;
XKeyEvent xkey;
XButtonEvent xbutton;
XMotionEvent xmotion;
XCrossingEvent xcrossing;
XFocusChangeEvent xfocus;
XExposeEvent xexpose;
XGraphicsExposeEvent xgraphicsexpose ;
XNoExposeEvent xnoexpose;
XVisibilityEvent xvisibility;
XCreateWindowEvent xcreatewindow;
XDestroyWindowEvent xdestroywindow;
XUnmapEvent xunmap;
XMapEvent xmap;
XMapRequestEvent xmaprequest;
XReparentEvent xreparent;
XConfigureEvent xconfigure;
XGravityEvent xgravity;
XResizeRequestEvent xresizerequest;
XConfigureRequestEvent xconfigurerequest;
XCirculateEvent xcirculate;
XCirculateRequestEvent xcirculaterequest;
XPropertyEvent xproperty;
XSelectionClearEvent xselectionclear;
XSelectionRequestEvent xselectionrequest;
XSelectionEvent xselection;
XColormapEvent xcolormap;
XClientMessageEvent xclient;
XMappingEvent xmapping;
XErrorEvent xerror;
XKeymapEvent xkeymap;
long pad[24];
/* must not be changed */
} XEvent;

An XEvent structure's first entry always is the type member, which is set to the event type. The second member always is the serial number of the protocol request that generated the event. The third member always is send_event, which is a Bool that indicates if the event was sent by a different client. The fourth member always is a display, which is the display that the event was read from. Except for keymap events, the fifth member always is a window, which has been carefully selected to be useful to toolkit dispatchers. To avoid breaking toolkits, the order of these first five entries is not to change. Most events also contain a time member, which is the time at which an event occurred. In addition, a pointer to the generic event must be cast before it is used to access any other information in the structure.

Home

10.3. Event Masks

Clients select event reporting of most events relative to a window. To do this, pass an event mask to an Xlib event-handling function that takes an event_mask argument. The bits of the event mask are defined in <X11/X.h>. Each bit in the event mask maps to an event mask name, which describes the event or events you want the X server to return to a client application.

Unless the client has specifically asked for them, most events are not reported to clients when they are generated. Unless the client suppresses them by setting graphics-exposures in the GC to False, GraphicsExpose and NoExpose are reported by default as a result of XCopyPlane and XCopyArea. SelectionClear, SelectionRequest, SelectionNotify, or ClientMessage cannot be masked. Selection related events are only sent to clients cooperating with selections (see section 4.5). When the keyboard or pointer mapping is changed, MappingNotify is always sent to clients.

The following table lists the event mask constants you can pass to the event_mask argument and the circumstances in which you would want to specify the event mask:

Event Mask Circumstances
NoEventMask
KeyPressMask
KeyReleaseMask
ButtonPressMask
ButtonReleaseMask
EnterWindowMask
LeaveWindowMask
PointerMotionMask
PointerMotionHintMask
Button1MotionMask
Button2MotionMask
Button3MotionMask
Button4MotionMask
Button5MotionMask
ButtonMotionMask
KeymapStateMask
ExposureMask
VisibilityChangeMask
StructureNotify Mask
ResizeRedirectMask
SubstructureNotifyMask
SubstructureRedirectMask
FocusChangeMask
PropertyChangeMask
ColormapChangeMask
OwnerGrabButtonMask
No events wanted
Keyboard down events wanted
Keyboard up events wanted
Pointer button down events wanted
Pointer button up events wanted
Pointer window entry events wanted
Pointer window leave events wanted
Pointer motion events wanted
Pointer motion hints wanted
Pointer motion while button 1 down
Pointer motion while button 2 down
Pointer motion while button 3 down
Pointer motion while button 4 down
Pointer motion while button 5 down
Pointer motion while any button down
Keyboard state wanted at window entry and focus in
Any exposure wanted
Any change in visibility wanted
Any change in window structure wanted
Redirect resize of this window
Substructure notification wanted
Redirect structure requests on children
Any change in input focus wanted
Any change in property wanted
Any change in colormap wanted
Automatic grabs should activate with owner_events set to True

Home


10.4. Event Processing Overview

The event reported to a client application during event processing depends on which event masks you provide as the event-mask attribute for a window. For some event masks, there is a one-to-one correspondence between the event mask constant and the event type constant. For example, if you pass the event mask ButtonPressMask, the X server sends back only ButtonPress events. Most events contain a time member, which is the time at which an event occurred.

In other cases, one event mask constant can map to several event type constants. For example, if you pass the event mask SubstructureNotifyMask, the X server can send back CirculateNotify, ConfigureNotify, CreateNotify, DestroyNotify, GravityNotify, MapNotify, ReparentNotify, or UnmapNotify events.

In another case, two event masks can map to one event type. For example, if you pass either PointerMotionMask or ButtonMotionMask, the X server sends back a MotionNotify event.

The following table lists the event mask, its associated event type or types, and the structure name associated with the event type. Some of these structures actually are typedefs to a generic structure that is shared between two event types. Note that N.A. appears in columns for which the information is not applicable.

Event Mask Event Type Structure Generic Structure
ButtonMotionMask
Button1MotionMask
Button2MofionMask
Button3MotionMask
Button4MotionMask
Button5MotionMask
MotionNotify XPointerMovedEven XMotionEvent
ButtonPressMask ButtonPress XButtonProssedEve nt XButtonEvent
ButtonReleaseMask ButtonRelease XButtonRelease dEvent XButtonEvent
ColormapChangeMask ColormapNotify XColormap Event  
EnterWindowMask EnterNotify XEnterWindowEve nt XCrossingEvent
LeaveWindowMask LeaveNotify XLeaveWindowEve nt XCrossingEvent
ExposureMask
GCGraphicsExposures in GC
Expose
GraphicsExpose
NoExpose
XExposeEvent
XGraphicsExposeEvent
XNoExposeEvent
 
FocusChangeMask FocusIn
FocusOut
XFocusInEvent
XFocusOutEvent
XFocusChangeEvent
XFocusChangeEvent
KeymapStateMask KeymapNotify XKeymapEvent  
KeyPressMask
Key Release Mask
KeyPress
KeyRelease
XKeyPressedEvent
XKeyReleasedEvent
XKeyEvent
XKeyEvent
OwnerGrabButtonMask N.A. N.A.  
PointerMotionMask
PointerMotionHintMask
MotionNotify
N.A.
XPointerMovedEvent
N.A.
XMotionEvent
PropertyChangeMask PropertyNotify XPropertyEve nt  
ResizeRedirectMask ResizeRequest XResizeRequest Event  
StructureNotifyMask CirculateNotify
ConfigureNotify
DestroyNotify
GravityNotify
MapNotify
ReparentNotify
UnmapNotify
XCirculateEvent
XConfigureEvent
XDestroyWindowEvent
XGravityEvent
XMapEvent
XReparentEvent
XUmnapEvent
 
SubstructureNotifyMask CirculateNotify
ConfigureNotify
CreateNotify
DestroyNotify
GravityNotify
MapNotify
ReparentNotify
UmnapNotify
XCirculateEvent
XConfigureEvent
XCreateWindowEvent
XDestroyWindowEvent
XGravityEvent
XMapEvent
XReparentEvent
XUnmapEvent
 
SubstructurcRedirectMask CirculateRequest
ConfigureRequest
MapRequest
XCirculateRequestEvent
XConfigureRequestEvent
XMapRequestEvent
 
N.A. ClientMessage XClientMessageEvent  
N.A. MappingNotify XMappingEvent  
N.A. SelectionClear XSelectionClearEvent  
N.A. SelectionNotify XSelectionEvent  
N.A. SelectionRequest XSelectionRequestEvent  
VisibilityChangeMask VisibilityNotify XVisibilityEv ent  

The sections that follow describe the processing that occurs when you select the different event masks. The sections are organized according to these processing categories:

Home

10.5. Keyboard and Pointer Events

This section discusses:

10.5.1. Pointer Button Events

The following describes the event processing that occurs when a pointer button press is processed with the pointer in some window w and when no active pointer grab is in progress.

The X server searches the ancestors of w from the root down, looking for a passive grab to activate. If no matching passive grab on the button exists, the X server automatically starts an active grab for the client receiving the event and sets the last-pointer-grab time to the current server time. The effect is essentially equivalent to an XGrabButton with these client passed arguments:

Argument Value
w
event_mask
pointer_mode
keyboard_mode
owner_events

confine_to
cursor
The event window
The client's selected pointer events on the event window
GrabModeAsync
GrabModeAsync
True
, if the client has selected OwnerGrabButtonMask on the event window, otherwise False
None
None

The active grab is automatically terminated when the logical state of the pointer has all buttons released. Clients can modify the active grab by calling XUngrabPointer and XChangeActivePointerGrab.

10.5.2. Keyboard and Pointer Events

This section discusses the processing that occurs for the keyboard events KeyPress and KeyRelease and the pointer events ButtonPress, ButtonRelease, and MotionNotify. For information about the keyboard event-handling utilities, refer to Chapter 11.

The X server reports KeyPress or KeyRelease events to clients wanting information about keys that logically change state. Note that these events are generated for all keys, even those mapped to modifier bits. The X server reports ButtonPress or ButtonRelease events to clients wanting information about buttons that logically change state.

The X server reports MotionNotify events to clients wanting information about when the pointer logically moves. The X server generates this event whenever the pointer is moved and the pointer motion begins and ends in the window. The granularity of MotionNotify events is not guaranteed, but a client that selects this event type is guaranteed to receive at least one event when the pointer moves and then rests.

The generation of the logical changes lags the physical changes if device event processing is frozen.

To receive KeyPress, KeyRelease, ButtonPress, and ButtonRelease events, set KeyPressMask, KeyReleaseMask, ButtonPressMask, and ButtonReleaseMask bits in the event-mask attribute of the window.

To receive MotionNotify events, set one or more of the following event masks bits in the event-mask attribute of the window.

The source of the event is the viewable window that the pointer is in. The window used by the X server to report these events depends on the window's position in the window hierarchy and whether any intervening window prohibits the generation of these events. Starting with the source window, the X server searches up the window hierarchy until it locates the first window specified by a client as having an interest in these events. If one of the intervening windows has its do-not-propagate-mask set to prohibit generation of the event type, the events of those types will be suppressed. Clients can modify the actual window used for reporting by performing active grabs and, in the case of keyboard events, by using the focus window.

The structures for these event types contain:

typedef struct {
int type;
unsigned long serial;
Bool send_event;
Display *display;
Window window;
Window root;
Window subwindow;
Time time;
int x, y;
int x_root, y_root;
unsigned int state;
unsigned int button;
Bool same_screen;
/* ButtonPress or ButtonRelease */
/* # of last request processed by server */
/* true if this came from a SendEvent request */
/* Display the event was read from */
/* "event" window it is reported relative to */
/* root window that the event occurred on */
/* child window */
/* milliseconds */
/* pointer x, y coordinates in event window */
/* coordinates relative to root */
/* key or button mask */
/* detail */
/* same screen flag */
} XButtonEvent;
typedef XButtonEvent XButtonPressedEvent;
typedef XButtonEvent XButtonReleasedEvent;

typedef struct {
int type;
unsigned long serial;
Bool send_event;
Display *display;
Window window;
Window root;
Window subwindow;
Time time;
int x, y;
int x_root, y_root;
unsigned int state;
unsigned int keycode;
Bool same_screen;
/* KeyPress or KeyRelease */
/* # of last request processed by server */
/* true if this came from a SendEvent request */
/* Display the event was read from */
/* "event" window it is reported relative to */
/* root window that the event occurred on */
/* child window */
/* milliseconds */
/* pointer x, y coordinates in event window */
/* coordinates relative to root */
/* key or button mask */
/* detail */
/* same screen flag */
} XKeyEvent;
typedef XKeyEvent XKeyPressedEvent;
typedef XKeyEvent XKeyReleasedEvent;
typedef struct {
int type;
unsigned long serial;
Bool send_event;
Display *display;
Window window;
Window root;
Window subwindow;
Time time;
int x, y;
int x_root, y_root;
unsigned int state;
char is_hint;
Bool same_screen;
/* MotionNotify */
/* # of last request processed by server */
/* true if this came from a SendEvent request */
/* Display the event was read from */
/* "event" window reported relative to */
/* root window that the event occurred on */
/* child window */
/* milliseconds */
/* pointer x, y coordinates in event window */
/* coordinates relative to root */
/* key or button mask */
/* detail */
/* same screen flag */
} XMotionEvent;
typedef XMotionEvent XPointerMovedEvent;

Home


These structures have the following common members: window, root, subwindow, time, x, y, x_root, y_root, state, and same_screen. The window member is set to the window on which the event was generated and is referred to as the event window. As long as the conditions previously discussed are met, this is the window used by the X server to report the event. The root member is set to the source window's root window. The x_root and y_root members are set to the pointer's coordinates relative to the root window's origin at the time of the event.

The same_screen member is set to indicate whether the event window is on the same screen as the root window and can be either True or False. If True, the event and root windows are on the same screen. If False, the event and root windows are not on the same screen.

If the source window is an inferior of the event window, the subwindow member of the structure is set to the child of the event window that is the source window or the child of the event window that is an ancestor of the source window. Otherwise, the X server sets the subwindow member to None. The time member is set to the time when the event was generated and is expressed in milliseconds.

If the event window is on the same screen as the root window, the x and y members are set to the coordinates relative to the event window's origin. Otherwise, these members are set to zero.

The state member is set to indicate the logical state of the pointer buttons and modifier keys just prior to the event, which is the bitwise inclusive OR of one or more of the button or modifier key masks: Button1Mask, Button2Mask, Button3Mask, Button4Mask, Button5Mask, ShiftMask, LockMask, ControlMask, Mod1Mask, Mod2Mask, Mod3Mask, Mod4Mask, and Mod5Mask.

Each of these structures also has a member that indicates the detail. For the XKeyPressedEvent and XKeyReleasedEvent structures, this member is called keycode. It is set to a number that represents a physical key on the keyboard. The keycode is an arbitrary representation for any key on the keyboard (see sections 12.7 and 16.1).

For the XButtonPressedEvent and XButtonReleasedEvent structures, this member is called button. It represents the pointer button that changed state and can be the Button1, Button2, Button3, Button4, or Button5 value. For the XPointerMovedEvent structure, this member is called is_hint. It can be set to NotifyNormal or NolifyHint.

Some of the symbols mentioned in this section have fixed values, as follows:

Symbol Value
Button1MotionMask
Button2MotionMask
Button3MotionMask
Button4MotionMask
Button5MotionMask
Button1Mask
Button2Mask
Button3Mask
Button4Mask
Button5Mask
ShiftMask
LockMask
ControlMask
Mod1Mask
Mod2Mask
Mod3Mask
Mod4Mask
Mod5Mask
Button1
Button2
Button3
Button4
Button5
(1L<<8)
(1L<<9)
(1L<<10)
(1L<<11)
(1L<<12)
(1<<8)
(1<<9)
(1<<10)
(1<<11)
(1<<12)
(1<<0)
(1<<1)
(1<<2)
(1<<3)
(1<<4)
(1<<5)
(1<<6)
(1<<7)
1
2
3
4
5

Home


10.6. Window Entry/Exit Events

This section describes the processing that occurs for the window crossing events EnterNotify and LeaveNotify. If a pointer motion or a window hierarchy change causes the pointer to be in a different window than before, the X server reports EnterNotify or LeaveNotify events to clients who have selected for these events. All EnterNotify and LeaveNotify events caused by a hierarchy change are generated after any hierarchy event (UnmapNotify, MapNotify, ConfigureNotify, GravityNotify, CirculateNotify) caused by that change; however, the X protocol does not constrain the ordering of EnterNotify and LeaveNotify events with respect to FocusOut, VisibilityNotify, and Expose events.

This contrasts with MotionNotify events, which are also generated when the pointer moves but only when the pointer motion begins and ends in a single window. An EnterNotify or LeaveNotify event also can be generated when some client application calls XGrabPointer and XUngrabPointer.

To receive EnterNotify or LeaveNotify events, set the EnterWindowMask or LeaveWindowMask bits of the event-mask attribute of the window.

The structure for these event types contains:

typedef struct {
int type;
unsigned long serial;
Bool send_event;
Display *display;
Window window;
Window root;
Window subwindow;
Time time;
int x,y;
int x_root, y_root;
int mode;
int detail;



Bool same_screen;
Bool focus;
unsigned int state;
/* EnterNotify or LeaveNoify */
/* # of last request processed by server */
/* true if this came from a SendEvent request */
/* Display the event was read from */
/* "event" window reported relative to */
/* root window that the event occurred on */
/* child window */
/* milliseconds */
/* pointer x, y coordinates in event window */
/* coordinates relative to root */
/* NotifyNormal, NotifyGrab, NotifyUngrab */
/*
* NotifyAncestor, NotifyVirtual, NoifyInferior,
* NotifyNonlinear,NotifyNonlinearVirtual
*/
/* same screen flag */
/* boolean focus */
/* key or button mask */
} XCrossingEvent;
typedef XCrossingEvent XEnterWindowEvent;
typedef XCrossingEvent XLeaveWindowEvent;

The window member is set to the window on which the EnterNotify or LeaveNotify event was generated and is referred to as the event window. This is the window used by the X server to report the event, and is relative to the root window on which the event occurred. The root member is set to the root window of the screen on which the event occurred.

For a LeaveNotify event, if a child of the event window contains the initial position of the pointer, the subwindow component is set to that child. Otherwise, the X server sets the subwindow member to None. For an EnterNotify event, if a child of the event window contains the final pointer position, the subwindow component is set to that child or None.

The time member is set to the time when the event was generated and is expressed in milliseconds. The x and y members are set to the coordinates of the pointer position in the event window. This position is always the pointer's final position, not its initial position. If the event window is on the same screen as the root window, x and y are the pointer coordinates relative to the event window's origin. Otherwise, x and y are set to zero. The x_root and y_root members are set to the pointer's coordinates relative to the root window's origin at the time of the event.

The same_screen member is set to indicate whether the event window is on the same screen its the root window and can be either True or False. If True, the event and root windows are on the same screen. If False, the event and root windows are not on the same screen.

The focus member is set to indicate whether the event window is the focus window or an inferior of the focus window. The X server can set this member to either True or False. If True, the event window is the focus window or an inferior of the focus window. If False, the event window is not the focus window or an inferior of the focus window.

The state member is set to indicate the state of the pointer buttons and modifier keys just prior to the event. The X server can set this member to the bitwise inclusive OR of one or more of the button or modifier key masks: Button1Mask, Button2Mask, Button3Mask, Button4Mask, Button5Mask, ShiftMask, LockMask, ControlMask, Mod1Mask, Mod2Mask, Mod3Mask, Mod4Mask, Mod5Mask.

The mode member is set to indicate whether the events are normal events, pseudo-motion events when a grab activates, or pseudo-motion events when a grab deactivates. The X server can set this member to NotifyNormal, NotifyGrab, or NotifyUngrab.

The detail member is set to indicate the notify detail and can be NotifyAncestor, NotifyVirtual, Notifylnferior, NotifyNonIinear, or NotifyNonlinearVirtual.

Home


10.6.1. Normal Entry/Exit Events

EnterNotify and LeaveNotify events are generated when the pointer moves from one window to another window. Normal events are identified by XEnterWindowEvent or XLeaveWindowEvent structures whose mode member is set to NotifyNormal.

Home


10.6.2. Grab and Ungrab Entry/Exit Events

Pseudo-motion mode EnterNotify and LeaveNotify events are generated when a pointer grab activates or deactivates. Events in which the pointer grab activates are identified by XEnterWindowEvent or XLeaveWindowEvent structures whose mode member is set to NotifyGrab. Events in which the pointer grab deactivates are identified by XEnterWindowEvent or XLeaveWindowEvent structures whose mode member is set to NotifyUngrab (see XGrabPointer).

Home

10.7. Input Focus Events

This section describes the processing that occurs for the input focus events FocusIn and FocusOut. The X server can report FocusIn or FocusOut events to clients wanting information about when the input focus changes. The keyboard is always attached to some window (typically, the root window or a top-level window), which is called the focus window. The focus window and the position of the pointer determine the window that receives keyboard input. Clients may need to know when the input focus changes to control highlighting of areas on the screen.

To receive FocusIn or FocusOut events, set the FocusChangeMask bit in the event-mask attribute of the window.

The structure for these event types contains:

typedef struct {
int type;
unsigned long serial;
Bool send_event;
Display *display;
Window window;
int mode;
int detail;
/* FocusIn or FocusOut */
/* # of last request processed by server */
/* true if this came from a SendEvent request */
/* Display the event was read from */
/* window of event */
/* NotifyNormal, NotifyGrab, NotifyUngrab */

/*
* NotifyAncestor, NotifyVirtual, NotifyInferior,
* NotifyNonlinear,NotifyNonlinearVirtual,
* NotifyPointer, Notify PointerRoot,
* Notify DetailNone
*/
} XFocusChangeEvent;
typedef XFocusChangeEvent XFocusInEvent;
typedef XFocusChangeEvent XFocusOutEvent;

The window member is set to the window on which the FocusIn or FocusOut event was generated. This is the window used by the X server to report the event. The mode member is set to indicate whether the focus events are normal focus events, focus events while grabbed, focus events when a grab activates, or focus events when a grab deactivates. The X server can set the mode member to NotifyNormal, NotifyWhileGrabbed, NotifyGrab, or NotifyUngrab.

All FocusOut events caused by a window unmap are generated after any UnmapNotify event; however, the X protocol does not constrain the ordering of FocusOut events with respect to generated EnterNotify, LeaveNotify, VisibilityNotify, and Expose events.

Depending on the event mode, the detail member is set to indicate the notify detail and can be NotifyAncestor, NotifyVirtual, NotifyInferior, NotifyNonlinear, NotifyNonlinearVirtual, NotifyPointer, NotifyPointerRoot, or NotifyDetailNone.

Home


10.7.1. Normal Focus Events and Focus Events While Grabbed

Normal focus events are identified by XFocusInEvent or XFocusOutEvent structures whose mode member is set to NotifyNormal. Focus events while grabbed are identified by XFocusInEvent or XFocusOutEvent structures whose mode member is set to NotifyWhileGrabbed. The X server processes normal focus and focus events while grabbed according to the following:

Home


10.7.2. Focus Events Generated by Grabs

Focus events in which the keyboard grab activates are identified by XFocusInEvent or XFocusOutEvent structures whose mode member is set to NotifyGrab. Focus events in which the keyboard grab deactivates are identified by XFocusInEvent or XFocusOutEvent structures whose mode member is set to NotifyUngrab (see XGrabKeyboard).

Home

10.8. Key Map State Notification Events

The X server can report KeymapNotify events to clients that want information about changes in their keyboard state.

To receive KeymapNotify events, set the KeymapStateMask bit in the event-mask attribute of the window. The X server generates this event immediately after every EnterNotify and FocusIn event.

The structure for this event type contains:

/* generated on EnterWindow and FocusIn when KeymapState selected */
typedef struct {
int type;
unsigned long serial;
Bool send_event;
Display *display;
Window window;
char key_vector[32];
/* KeymapNotify */
/* # of last request processed by server */
/* true if this came from a SendEvent request */
/* Display the event was read from */
} XKeymapEvent;

The window member is not used but is present to aid some toolkits. The key_vector member is set to the bit vector of the keyboard. Each bit set to 1 indicates that the corresponding key is currently pressed. The vector is represented as 32 bytes. Byte N (from 0) contains the bits for keys 8N to 8N + 7 with the least-significant bit in the byte representing key 8N.

Home

10.9. Exposure Events

The X protocol does not guarantee to preserve the contents of window regions when the windows are obscured or reconfigured. Some implementations may preserve the contents of windows. Other implementations are free to destroy the contents of windows when exposed. X expects client applications to assume the responsibility for restoring the contents of an exposed window region. (An exposed window region describes a formerly obscured window whose region becomes visible.) Therefore, the X server sends Expose events describing the window and the region of the window that has been exposed. A naive client application usually redraws the entire window. A more sophisticated client application redraws only the exposed region.

10.9.1. Expose Events

The X server can report Expose events to clients wanting information about when the contents of window regions have been lost. The circumstances in which the X server generates Expose events are not as definite as those for other events. However, the X server never generates Expose events on windows whose class you specified as InputOnly. The X server can generate Expose events when no valid contents are available for regions of a window and either the regions are visible, the regions are viewable and the server is (perhaps newly) maintaining backing store on the window, or the window is not viewable but the server is (perhaps newly) honoring the window's backing-store attribute of Always or WhenMapped. The regions decompose into an (arbitrary) set of rectangles, and an Expose event is generated for each rectangle. For any given window, the X server guarantees to report contiguously all of the regions exposed by some action that causes Expose events, such as raising a window.

To receive Expose events, set the ExposureMask bit in the event-mask attribute of the window.

The structure for this event type contains:

typedef struct {
int type;
unsigned long serial;
Bool send_event;
Display *display;
Window window;
int x, y;
int width, height;
int count;
/* Expose */
/* # of last request processed by server */
/* true if this came from a SendEvent request */
/* Display the event was read from */



/* if nonzero, at least this many more */
} XExposeEvent;

The window member is set to the exposed (damaged) window. The x and y members are set to the coordinates relative to the window's origin and indicate the upper-left corner of the rectangle. The width and height members are set to the size (extent) of the rectangle. The count member is set to the number of Expose events that are to follow. If count is zero, no more Expose events follow for this window. However, if count is nonzero, at least that number of Expose events (and possibly more) follow for this window. Simple applications that do not want to optimize redisplay by distinguishing between subareas of its window can just ignore all Expose events with nonzero counts and perform full redisplays on events with zero counts.

Home


10.9.2. GraphicsExpose and NoExpose Events

The X server can report GraphicsExpose events to clients wanting information about when a destination region could not be computed during certain graphics requests: XCopyArea or XCopyPlane. The X server generates this event whenever a destination region could not be computed due to an obscured or out-of-bounds source region. In addition, the X server guarantees to report contiguously all of the regions exposed by some graphics request (for example, copying an area of a drawable to a destination drawable).

The X server generates a NoExpose event whenever a graphics request that might produce a GraphicsExpose event does not produce any. In other words, the client is really asking for a GraphicsExpose event but instead receives a NoExpose event.

9 To receive GraphicsExpose or NoExpose events, you must first set the graphics-exposure attribute of the graphics context to True. You also can set the graphics-expose attribute when creating a graphics context using XCreateGC or by calling XSetGraphicsExposures.

The structures for these event types contain:

typedef struct {
int type;
unsigned long serial;
Bool send_event;
Display *display;
Drawable drawable;
int x, y;
int width, height;
int count;
int major_code;
int minor_code;
/* GraphicsExpose */
/* # of last request processed by server */
/* true if this came from a SendEvent request */
/* Display the event was read from */



/* if nonzero, at least this many more */
/* core is CopyArea or CopyPlane */
/* not defined in the core */
} XGraphicsExposeEvent;
typedef struct {
int type;
unsigned long serial;
Bool send_event;
Display *display;
Drawable drawable;
int major_code;
int minor_code;
/* NoExpose */
/* # of last request processed by server */
/* true if this came from a SendEvent request */
/* Display the event was read from */

/* core is CopyArea or CopyPlane */
/* not defined in the core */
} XNoExposeEvent;

Both structures have these common members: drawable, major_code, and minor_code. The drawable member is set to the drawable of the destination region on which the graphics request was to be performed. The major_code member is set to the graphics request initiated by the client and can be either X_CopyArea or X_CopyPlane. If it is X_CopyArea, a call to XCopyArea initiated the request. If it is X_CopyPlane, a call to XCopyPlane initiated the request. These constants are defined in <X11/Xproto.h>. The minor_code member, like the major_code member, indicates which graphics request was initiated by the client. However, the minor_code member is not defined by the core X protocol and will be zero in these cases, although it may be used by an extension.

The XGraphicsExposeEvent structure has these additional members: x, y, width, height, and count. The x and y members are set to the coordinates relative to the drawable's origin and indicate the upper-left corner of the rectangle. The width and height members are set to the size (extent) of the rectangle. The count member is set to the number of GraphicsExpose events to follow. If count is zero, no more GraphicsExpose events follow for this window. However, if count is nonzero, at least that number of GraphicsExpose events (and possibly more) are to follow for this window.

Home

10.10. Window State Change Events

The following sections discuss:

10.10.1. CirculateNotify Events

The X server can report CirculateNotify events to clients wanting information about when a window changes its position in the stack. The X server generates this event type whenever a window is actually restacked as a result of a client application calling XCirculateSubwindows, XCirculateSubwindowsUp, or XCirculateSubwindowsDown.

To receive CirculateNotify events, set the StructureNotifyMask bit in the event-mask attribute of the window or the SubstructureNotifyMask bit in the event-mask attribute of the parent window (in which case, circulating any child generates an event).

The structure for this event type contains:

typedef struct {
int type;
unsigned long serial;
Bool send_event;
Display *display;
Window event;
Window window;
int place;
/* CirculateNotify */
/* # of last request processed by server */
/* true if this came from a SendEvent request */
/* Display the event was read from */


/* PlaceOnTop, PlaceOnBottom */
} XCirculateEvent;

The event member is set either to the restacked window or to its parent, depending on whether StructureNotify or SubstructureNotify was selected. The window member is set to the window that was restacked. The place member is set to the window's position after the restack occurs and is either PlaceOnTop or PlaceOnBottom. If it is PlaceOnTop, the window is now on top of all siblings. If it is PlaceOnBottom, the window is now below all siblings.

Home


10.10.2. ConfigureNotify Events

The X server can report ConfigureNotify events to clients wanting information about actual changes to a window's state, such as size, position, border, and stacking order. The X server generates this event type whenever one of the following configure window requests made by a client application actually completes:

To receive ConfigureNotify events, set the StructureNotifyMask bit in the event-mask attribute of the window or the SubstructureNotifyMask bit in the event-mask attribute of the parent window (in which case, configuring any child generates an event).

The structure for this event type contains:

typedef struct {
int type;
unsigned long serial;
Bool send_event;
Display *display;
Window event;
Window window;
int x, y;
int width, height;
int border_width;
Window above;
Bool override_redirect;
/* ConfigureNotify */
/* # of last request processed by server */
/* true if this came from a SendEvent request */
/* Display the event was read from */
} XConfigureEvent;

The event member is set either to the reconfigured window or to its parent, depending on whether StructureNotify or SubstructureNotify was selected. The window member is set to the window whose size, position, border, and/or stacking order was changed.

The x and y members are set to the coordinates relative to the parent window's origin and indicate the position of the upper-left outside corner of the window. The width and height members are set to the inside size of the window, not including the border. The border_width member is set to the width of the window's border, in pixels.

The above member is set to the sibling window and is used for stacking operations. If the X server sets this member to None, the window whose state was changed is on the bottom of the stack with respect to sibling windows. However, if this member is set to a sibling window, the window whose state was changed is placed on top of this sibling window.

The override_redirect member is set to the override-redirect attribute of the window. Window manager clients normally should ignore this window if the override_redirect member is True.

Home


10.10.3. CreateNotify Events

The X server can report CreateNotify events to clients wanting information about creation of windows. The X server generates this event whenever a client application creates a window by calling XCreateWindow or XCreateSimpleWindow.

To receive CreateNotify events, set the SubstructureNotifyMask bit in the event-mask attribute of the window. Creating any children then generates an event.

The structure for the event type contains:

typedef struct {
int type;
unsigned long serial;
Bool send_event;
Display *display;
Window parent;
Window window;
int x, y;
int width, height;
int border_width;
Bool override_redirect;
/* CreateNotify */
/* # of last request processed by server */
/* true if this came from a SendEvent request */
/* Display the event was read from */
/* parent of the window */
/* window id of window created */
/* window location */
/* size of window */
/* border width */
/* creation should be overridden */
} XCreateWindowEvent;

The parent member is set to the created window's parent. The window member specifies the created window. The x and y members are set to the created window's coordinates relative to the parent window's origin and indicate the position of the upper-left outside corner of the created window. The width and height members are set to the inside size of the created window (not including the border) and are always nonzero. The border_width member is set to the width of the created window's border, in pixels. The override_redirect member is set to the override-redirect attribute of the window. Window manager clients normally should ignore this window if the override_redirect member is True.

10.10.4. DestroyNotify Events

The X server can report DestroyNotify events to clients wanting information about which windows are destroyed. The X server generates this event whenever a client application destroys a window by calling XDestroyWindow or XDestroySubwindows.

The ordering of the DestroyNotify events is such that for any given window, DestroyNotify is generated on all inferiors of the window before being generated on the window itself. The X protocol does not constrain the ordering among, siblings and across subhierarchies.

To receive DestroyNotify events, set the StructureNotifyMask bit in the event-mask attribute of the window or the SubstructureNotifyMask bit in the event-mask attribute of the parent window (in which case, destroying any child generates an event).

The structure for this event type contains:

typedef struct {
int type;
unsigned long serial;
Bool send_event;
Display *display;
Window event;
Window window;
/* DestroyNotify */
/* # of last request processed by server */
/* true if this came from a SendEvent request */
/* Display the event was read from */
} XDestroyWindowEvent;

The event member is set either to the destroyed window or to its parent, depending on whether StructureNotify or SubstructureNotify was selected. The window member is set to the window that is destroyed.

Home


10.10.5. GravityNotify Events

The X server can report GravityNotify events to clients wanting information about when a window is moved because of a change in the size of its parent. The X server generates this event whenever a client application actually moves a child window as a result of resizing its parent by calling XConfigureWindow, XMoveResizeWindow, or XResizeWindow.

To receive GravityNotify events, set the StructureNotifyMask bit in the event-mask attribute of the window or the SubstructureNotifyMask bit in the event-mask attribute of the parent window (in which case, any child that is moved because its parent has been resized generates an event).

The structure for this event type contains:

typedef struct {
int type;
unsigned long serial;
Bool send_event;
Display *display;
Window event;
Window window;
intx,y;
/* GravityNotify */
/* # of last request processed by server */
/* true if this came from a SendEvent request */
/* Display the event was read from */
} XGravityEvent;

The event member is set either to the window that was moved or to its parent, depending on whether StructureNotify or SubstructureNotify was selected. The window member is set to the child window that was moved. The x and y members are set to the coordinates relative to the new parent window's origin and indicate the position of the upper-left outside corner of the window.

10.10.6. MapNotify Events

The X server can report MapNotify events to clients wanting information about which windows are mapped. The X server generates this event type whenever a client application changes the window's state from unmapped to mapped by calling XMapWindow, XMapRaised, XMapSubwindows, XReparentWindow, or as a result of save-set processing.

To receive MapNotify events, set the StructureNotifyMask bit in the event-mask attribute of the window or the SubstructureNotifyMask bit in the event-mask attribute of the parent window (in which case, mapping any child generates an event).

The structure for this event type contains:

typedef struct {
int type;
unsigned long serial;
Bool send_event;
Display *display;
Window event;
Window window;
Bool override_redirect;
/* MapNotify */
/* # of last request processed by server */
/* true if this came from a SendEvent request */
/* Display the event was read from */


/* boolean, is override set... */
} XMapEvent;

The event member is set either to the window that was mapped or to its parent, depending on whether StructureNotify or SubstructureNotify was selected. The window member is set to the window that was mapped. The override_redirect member is set to the override-redirect attribute of the window. Window manager clients normally should ignore this window if the override-redirect attribute is True, because these events usually are generated from pop-ups, which override structure control.

Home


10.10.7. MappingNotify Events

The X server reports MappingNotify events to all clients. There is no mechanism to express disinterest in this event. The X server generates this event type whenever a client application successfully calls:

The structure for this event type contains:

typedef struct {
int type;
unsigned long serial;
Bool send_event;
Display *display;
Window window;
int request;

int first_keycode;
int count;
/* MappingNotify */
/* # of last request processed by server */
/* true if this came from a SendEvent request */
/* Display the event was read from */
/* unused */
/* one of MappingModifier,MappingKeyboard,
MappingPointer */
/* first keycode */
/* defines range of change w. first_keycode*/
} XMappingEvent;

The request member is set to indicate the kind of mapping change that occurred and can be MappingModifier, MappingKeyboard, MappingPointer. If it is MappingModifier, the modifier mapping was changed. If it is MappingKeyboard, the keyboard mapping was changed. If it is MappingPointer, the pointer button mapping was changed. The first_keycode and count members are set only if the request member was set to MappingKeyboard. The number in first_keycode represents the first number in the range of the altered mapping, and count represents the number of keycodes altered.

To update the client application's knowledge of the keyboard, you should call XRefreshKeyboardMapping.

10.10.8. ReparentNotify Events

The X server can report ReparentNotify events to clients wanting information about changing a window's parent. The X server generates this event whenever a client application calls XReparentWindow and the window is actually reparented.

To receive ReparentNotify events, set the StructureNotifyMask bit in the event-mask attribute of the window or the SubstructureNotifyMask bit in the event-mask attribute of either the old or the new parent window (in which case, reparenting any child generates an event).

The structure for this event type contains:

typedef struct {
int type;
unsigned long serial;
Bool send_event;
Display *display;
Window event;
Window window;
Window parent;
int x, y;
Bool override_redirect;
/* ReparentNotify */
/* # of last request processed by server */
/* true if this came from a SendEvent request */
/* Display the event was read from */
} XReparentEvent;

The event member is set either to the reparented window or to the old or the new parent, depending on whether StructureNotify or SubstructureNotify was selected. The window member is set to the window that was reparented. The parent member is set to the new parent window. The x and y members are set to the reparented window's coordinates relative to the new parent window's origin and define the upper-left outer corner of the reparented window. The override_redirect member is set to the override-redirect attribute of the window specified by the window member. Window manager clients normally should ignore this window if the override_redirect member is True.

Home


10.10.9. UnmapNotify Events

The X server can report UnmapNotify events to clients wanting information about which windows are unmapped. The X server generates this event type whenever a client application changes the window's state from mapped to unmapped.

To receive UnmapNotify events, set the StructureNotifyMask bit in the event-mask attribute of the window or the SubstructureNotifyMask bit in the event-mask attribute of the parent window (in which case, unmapping any child window generates an event).

The structure for this event type contains:

typedef struct {
int type;
unsigned long serial;
Bool send_event;
Display *display;
Window event;
Window window;
Bool from_configure;
/* UnmapNotify */
/* # of last request processed by server */
/* true if this came from a SendEvent request */
/* Display the event was read from */
} XUnmapEvent;

The event member is set either to the unmapped window or to its parent, depending on whether StructureNotify or SubstructureNotify was selected. This is the window used by the X server to report the event. The window member is set to the window that was unmapped. The from_configure member is set to True if the event was generated as a result of a resizing of the window's parent when the window itself had a win_gravity of UnmapGravity.

10.10.10. VisibilityNotify Events

The X server can report VisibilityNotify events to clients wanting any change in the visibility of the specified window. A region of a window is visible if someone looking at the screen can actually see it. The X server generates this event whenever the visibility changes state. However, this event is never generated for windows whose class is InputOnly.

All VisibilityNotify events caused by a hierarchy change are generated after any hierarchy event (UnmapNotify, MapNotify, ConfigureNotify, GravityNotify, CirculateNotify) caused by that change. Any VisibilityNotify event on a given window is generated before any Expose events on that window, but it is not required that all VisibilityNotify events on all windows be generated before all Expose events on all windows. The X protocol does not constrain the ordering of VisibilityNotify events with respect to FocusOut, EnterNotify, and LeaveNotify events.

To receive VisibilityNotify events, set the VisibilityChangeMask bit in the event-mask attribute of the window.

The structure for this event type contains:

typedef struct {
int type;
unsigned long serial;
Bool send_event;
Display *display;
Window window;
int state;
/* VisibiltyNotify */
/* # of last request processed by server */
/* true if this came from a SendEvent request */
/* Display the event was read from */
} XVisibilityEvent;

The window member is set to the window whose visibility state changes. The state member is set to the state of the window's visibility and can be VisibilityUnobscured, VisibilityPartiallyObscured, or VisibilityFullyObscured. The X server ignores all of a window's subwindows when determining the visibility state of the window and processes VisibilityNotify events according to the following:

Home

10.11. Structure Control Events

This section discusses:

10.11.1. CirculateRequest Events

The X server can report CirculateRequest events to clients waning information about when another client initiates a circulate window request on a specified window. The X server generates this event type whenever a client initiates a circulate window request on a window and a subwindow actually needs to be restacked. The client initiates a circulate window request on the window by calling XCirculateSubwindows, XCirculateSubwindowsUp, or XCirculateSubwindowsDown.

To receive CirculateRequest events, set the SubstructureRedirectMask in the event-mask attribute of the window. Then, in the future, the circulate window request for the specified window is not executed, and thus, any subwindow's position in the stack is not changed. For example, suppose a client application calls XCirculateSubwindowsUp to raise a subwindow to the top of the stack. If you had selected SubstructureRedirectMask on the window, the X server reports to you a CirculateRequest event and does not raise the subwindow to the top of the stack.

The structure for this event type contains:

typedef struct {
int type;
unsigned long serial;
Bool send_event;
Display *display;
Window parent;
Window window;
int place;
/* CirculateRequest */
/* # of last request processed by server */
/* true if this came from a SendEvent request */
/* Display the event was read from */


/* PlaceOnTop, PlaceOnBottom */
} XCirculateRequestEvent;

The parent member is set to the parent window. The window member is set to the subwindow to be restacked. The place member is set to what the new position in the stacking order should be and is either PlaceOnTop or PlaceOnBottom. If it is PlaceOnTop, the subwindow should be on top of all siblings. If it is PlaceOnBottom, the subwindow should be below all siblings.

10.11.2. ConfigureRequest Events

The X server can report ConfigureRequest events to clients wanting information about when a different client initiates a configure window request on any child of a specified window. The configure window request attempts to reconfigure a window's size, position, border, and stacking order. The X server generates this event whenever a different client initiates a configure window request on a window by calling XConfigureWindow, XLowerWindow, XRaiseWindow, XMapRaised, XMoveResizeWindow, XMoveWindow, XResizeWindow, XRestackWindows, or XSetWindowBorderWidth.

To receive ConfigureRequest events, set the SubstructureRedirectMask bit in the event-mask attribute of the window. ConfigureRequest events are generated when a ConfigureWindow protocol request is issued on a child window by another client. For example, suppose a client application calls XLowerWindow to lower a window. If you had selected SubstructureRedirectMask on the parent window and if the override-redirect attribute of the window is set to False, the X server reports a ConfigureRequest event to you and does not lower the specified window.

The structure for this event type contains:

typedef struct {
int type;
unsigned long serial;
Bool send_event;
Display *display;
Window parent;
Window window;
int x, y;
int width, height;
int border_width;
Window above;
int detail;
unsigned long value_mask;
/* ConfigureRequest */
/* # of last request processed by server */
/* true if this came from a SendEvent request */
/* Display the event was read from */






/* Above, Below, TopIf, BottomIf, Opposite */
} XConfigureRequestEvent;

The parent member is set to the parent window. The window member is set to the window whose size, position, border width, and/or stacking order is to be reconfigured. The value_mask member indicates which components were specified in the ConfigureWindow protocol request. The corresponding values are reported as given in the request. The remaining values are filled in from the current geometry of the window, except in the case of above (sibling) and detail (stack-mode), which are reported as None and Above, respectively, if they are not given in the request.

Home


10.11.3. MapRequest Events

The X server can report MapRequest events to clients wanting information about a different client's desire to map windows. A window is considered mapped when a map window request completes. The X server generates this event whenever a different client initiates a map window request on an unmapped window whose override_redirect member is set to False. Clients initiate map window requests by calling XMapWindow, XMapRaised, or XMapSubwindows.

To receive MapRequest events, set the SubstructureRedirectMask bit in the event-mask attribute of the window. This means another client's attempts to map a child window by calling one of the map window request functions is intercepted, and you are sent a MapRequest instead. For example, suppose a client application calls XMapWindow to map a window. If you (usually a window manager) had selected SubstructureRedirectMask on the parent window and if the override-redirect attribute of the window is set to False, the X server reports a MapRequest event to you and does not map the specified window. Thus, this event gives your window manager client the ability to control the placement of subwindows.

The structure for this event type contains:

typedef struct {
int type;
unsigned long serial;
Bool send_event;
Display *display;
Window parent;
Window window;
/* MapRequest */
/* # of last request processed by server */
/* true if this came from a SendEvent request */
/* Display the event was read from */
} XMapRequestEvent;

The parent member is set to the parent window. The window member is set to the window to be mapped.

10.11.4. ResizeRequestEvents

The X server can report ResizeRequest events to clients wanting information about another client's attempts to change the size of a window. The X server generates this event whenever some other client attempts to change the size of the specified window by calling XConfigureWindow, XResizeWindow, or XMoveResizeWindow.

To receive ResizeRequest events, set the ResizeRedirect bit in the event-mask attribute of the window. Any attempts to change the size by other clients are then redirected.

The structure for this event type contains:

typedef struct {
int type;
unsigned long serial;
Bool send_event;
Display *display;
Window window;
int width, height;
/* ResizeRequest */
/* # of last request processed by server */
/* true if this came from a SendEvent request */
/* Display the event was read from */
} XResizeRequestEvent;

The window member is set to the window whose size another client attempted to change. The width and height members are set to the inside size of the window, excluding the border.

Home

10.12. Colormap State Change Events

The X server can repon ColormapNotify events to clients wanting information about when the colormap changes and when a colormap is installed or uninstalled. The X server generates this event type whenever a client application:

To receive ColormapNotify events, set the ColormapChangeMask bit in the event-mask attribute of the window.

The structure for this event type contains:

typedef struct {
int type;
unsigned long serial;
Bool send_event;
Display *display;
Window window;
Colormap colormap;
Bool new;
int state;
/* ColormapNotify */
/* # of last request processed by server */
/* true if this came from a SendEvent request */
/* Display the event was read from */

/* colormap or None */

/* ColormapInstalled, ColormapUninstalled */
} XColormapEvent;

The window member is set to the window whose associated colormap is changed, installed, or uninstalled. For a colormap that is changed, installed, or uninstalled, the colormap member is set to the colormap associated with the window. For a colormap that is changed by a call to XFreeColormap, the colormap member is set to None. The new member is set to indicate whether the colormap for the specified window was changed or installed or uninstalled and can be True or False. If it is True, the colormap was changed. If it is False, the colormap was installed or uninstalled. The state member is always set to indicate whether the colormap is installed or uninstalled and can be ColormapInstalled or ColormapUninstalled.

Home

10.13. Client Communication Events

This section discusses:

10.13.1. ClientMessage Events

The X server generates ClientMessage events only when a client calls the function XSendEvent.

The structure for this event type contains:

typedef struct {
int type;
unsigned long serial;
Bool send_event;
Display *display;
Window window;
Atom message_type;
int format;
union {
/* ClientMessage */
/* # of last request processed by server */
/* true if this came from a SendEvent request */
/* Display the event was read from */
char b[20];
short s[10];
long 1[5];
} data;
} XClientMessageEvent;

The message_type member is set to an atom that indicates how the data should be interpreted by the receiving client. The format member is set to 8, 16, or 32 and specifies whether the data should be viewed as a list of bytes, shorts, or longs. The data member is a union that contains the members b, s, and 1. The b, s, and l members represent data of 20 8-bit values, 10 16-bit values, and 5 32-bit values. Particular message types might not make use of all these values. The X server places no interpretation on the values in the window, message_type, or data members.

10.13.2. PropertyNotify Events

The X server can report PropertyNotify events to clients wanting information about property changes for a specified window.

To receive PropertyNotify events, set the PropertyChangeMask bit in the event-mask attribute of the window.

The structure for this event type contains:

typedef struct {
int type;
unsigned long serial;
Bool send_event;
Display *display;
Window window;
Atom atom;
Time time;
int state;
/* PropertyNotify */
/* # of last request processed by server */
/* true if this came from a SendEvent request */
/* Display the event was read from */



/* PropertyNewValue or PropertyDelete */
} XPropertyEvent;

The window member is set to the window whose associated property was changed. The atom member is set to the property's atom and indicates which property was changed or desired. The time member is set to the server time when the property was changed. The state member is set to indicate whether the property was changed to a new value or deleted and can be PropertyNewValue or PropertyDelete. The state member is set to PropertyNewValue when a property of the window is changed using XChangeProperty or XRotateWindowProperties (even when adding zero-length data using XChangeProperty) and when replacing all or pan of a property with identical data using XChangeProperty or XRotateWindowProperties. The state member is set to PropertyDelete when a property of the window is deleted using XDeleteProperty or, if the delete argument is True, XGetWindowProperty.

10.13.3. SelectionClear Events

The X server reports SelectionClear events to the client losing ownership of a selection. The X server generates this event type when another client asserts ownership of the selection by calling XSetSelectionOwner.

The structure for this event type contains:

typedef struct {
int type;
unsigned long serial;
Bool send_event;
Display *display;
Window window;
Atom selection;
Time time;
/* SelectionClear */
/* # of last request processed by server */
/* true if this came from a SendEvent request */
/* Display the event was read from */
} XSelectionClearEvent;

The selection member is set to the selection atom. The time member is set to the last change time recorded for the selection. The window member is the window that was specified by the current owner (the owner losing the selection) in its XSetSelectionOwner call.

Home


10.13.4. SelectionRequest Events

The X server reports SelectionRequest events to the owner of a selection. The X server generates this event whenever a client requests a selection conversion by calling XConvertSelection for the owned selection.

The structure for this event type contains:

typedef struct {
int type;
unsigned long serial;
Bool send_event;
Display *display;
Window owner;
Window requestor;
Atom selection;
Atom target;
Atom property;
Time time;
/* SelectionRequest */
/* # of last request processed by server */
/* true if this came from a SendEvent request */
/* Display the event was read from */
} XSelectionRequestEvent;

The owner member is set to the window that was specified by the current owner in its XSetSelectionOwner call. The requestor member is set to the window requesting the selection. The selection member is set to the atom that names the selection. For example, PRIMARY is used to indicate the primary selection. The target member is set to the atom that indicates the type the selection is desired in. The property member can be a property name or None. The time member is set to the timestamp or CurrentTime value from the ConvertSelection request.

The owner should convert the selection based on the specified target type and send a SelectionNotify event back to the requestor. A complete specification for using selections is given in the X Consortium standard Inter-Client Communication Conventions in the SUPER-UX X Window System Programmer's Guide.

10.13.5. SelectionNotify Events

This event is generated by the X server in response to a ConvertSelection protocol request when there is no owner for the selection. When there is an owner, it should be generated by the owner of the selection by using XSendEvent. The owner of a selection should send this event to a requestor when a selection has been converted and stored as a property or when a selection conversion could not be performed (which is indicated by setting the property member to None).

If None is specified as the property in the ConvertSelection protocol request, the owner should choose a property name, store the result as that property on the requestor window, and then send a SelectionNotify giving that actual property name.

The structure for this event type contains:

typedef struct {
int type;
unsigned long serial;
Bool send_event;
Display *display;
Window requestor;
Atom selection;
Atom target;
Atom property;
Time time;
/* SelectionNotify */
/* # of last request processed by server */
/* true if this came from a SendEvent request */
/* Display the event was read from */



/* atom or None */
} XSelectionEvent;

The requestor member is set to the window associated with the requestor of the selection. The selection member is set to the atom that indicates the selection. For example, PRIMARY is used for the primary selection. The target member is set to the atom that indicates the converted type. For example, PIXMAP is used for a pixmap. The property member is set to the atom that indicates which property the result was stored on. If the conversion failed, the property member is set to None. The time member is set to the time the conversion took place and can be a timestamp or CurrentTime.

Home

Contents Previous Chapter Next Chapter