XtAppNextEvent(3)
β¨ XtAppNextEvent β query and process events and input β¨
okay bestie, sit down, hydrate, and let me tell you about the XtAppNextEvent family, aka the X Toolkit Intrinsics functions from the XT FUNCTIONS section of the manual. this is the group chat where events get picked up, peeked at, processed, dispatched, and looped forever. it's giving main character energy for literally every Xt application π
the whole squad is: XtAppNextEvent, XtAppPending, XtAppPeekEvent, XtAppProcessEvent, XtDispatchEvent, and XtAppMainLoop. yes queen, six functions, one page, all iconic.
π¦ SYNTAX π¦
#include <X11/Intrinsic.h>
void XtAppNextEvent(XtAppContext app_context, XEvent *event_return);
Boolean XtAppPeekEvent(XtAppContext app_context, XEvent *event_return);
XtInputMask XtAppPending(XtAppContext app_context);
void XtAppProcessEvent(XtAppContext app_context, XtInputMask mask);
Boolean XtDispatchEvent(XEvent *event);
void XtAppMainLoop(XtAppContext app_context);
like, that's the whole vibe right there. no cap. πΈ
πΈ ARGUMENTS πΈ
app_contextβ the application context that identifies the application. it's literally the lil ID card your app carries around so the toolkit knows who's who πeventβ a pointer to the event structure that is to be dispatched to the appropriate event handler. this one's forXtDispatchEventspecifically, iykyk.event_returnβ returns the event information to the specified event structure. so the function hands the event back to you in here πmaskβ specifies what types of events to process. it's the bitwise inclusive OR of any combination ofXtIMXEvent,XtIMTimer,XtIMAlternateInput, andXtIMSignal. and as a lil convenience, the X Toolkit defines the symbolic nameXtIMAllto be the bitwise inclusive OR of all event types. so like, "everything please" π«Ά
π DESCRIPTION π
not me explaining the whole event pipeline π«Ά
if the X event queue is empty, XtAppNextEvent flushes the X output buffers of each Display in the application context and waits for an event β while also looking at the other input sources, timeout timeout values, and signal handlers, and calling any callback procedures triggered by them. and bestie, this wait time can be used for background processing (see Section 7.8). productive queen behavior, honestly.
XtAppPeekEvent π
if there's an event in the queue, XtAppPeekEvent fills in the event and returns a nonzero value. if no X input is on the queue, it flushes the output buffer and blocks until input is available (possibly calling some timeout callbacks in the process, no big deal). if that input is an event, XtAppPeekEvent fills in the event and returns a nonzero value. otherwise β plot twist β the input is for an alternate input source, and XtAppPeekEvent returns zero. so like, zero means "not an event bestie, that's someone else's business" π
XtAppPending β³
XtAppPending returns a nonzero value if there are events pending from the X server, timer pending, or other input sources pending. the value returned is a bit mask that is the OR of XtIMXEvent, XtIMTimer, XtIMAlternateInput, and XtIMSignal (see XtAppProcessEvent). if there are no events pending, XtAppPending flushes the output buffer and returns zero. simple as that, periodt.
XtAppProcessEvent π―
XtAppProcessEvent processes one timer, alternate input, signal source, or X event. one. singular. if there's nothing of the appropriate type to process, it blocks until there is. if there's more than one type of thing available to process, it is undefined which will get processed β so don't come for me when you can't predict it, that's literally the spec π
usually, this procedure is not called by client applications (see XtAppMainLoop). XtAppProcessEvent processes timer events by calling any appropriate timer callbacks, alternate input by calling any appropriate alternate input callbacks, signal source by calling any appropriate signal callbacks, and X events by calling XtDispatchEvent. so it's like the bouncer at the club, routing everyone to the right room π
XtDispatchEvent π¬
when an X event is received, it's passed to XtDispatchEvent, which calls the appropriate event handlers and passes them the widget, the event, and client-specific data registered with each procedure. if there are no handlers for that event registered, the event is ignored and the dispatcher simply returns. and the order in which the handlers are called is undefined β so don't be out here assuming an order, bestie, there isn't one π
XtDispatchEvent sends those events to the event handler functions that have been previously registered with the dispatch routine. it returns True if it dispatched the event to some handler and False if it found no handler to dispatch the event to.
the most common use of XtDispatchEvent is to dispatch events acquired with the XtAppNextEvent procedure. however, it also can be used to dispatch user-constructed events. and it's also responsible for implementing the grab semantics for XtAddGrab. multitasking icon π
XtAppMainLoop π
XtAppMainLoop processes events using XtAppProcessEvent, varying the mask parameter and using XtAppPending to ensure that it has a chance to handle events of all types β i.e., X events, timer events, input events and signal sources. this constitutes the main loop of X Toolkit applications, and, as such, it does not return unless XtAppSetExitFlag is called. like, it will simply not leave. applications are expected to exit in response to some user action. there is nothing special about XtAppMainLoop; it's simply an loop that processes events until XtAppGetExitFlag() returns true. lowercase iconic behavior tbh β¨
applications can provide their own version of this loop, which tests some global termination flag or tests that the number of top-level widgets is larger than zero before circling back for the next event. do it yourself if you want, we support you π«Ά
ngl, "it is simply an loop" is in the original and I am keeping it exactly as-is because facts don't change just because the grammar is a lil quirky. that's the rule, and I respect the rule π
π SEE ALSO π
X Toolkit Intrinsics - C Language InterfaceXlib - C Language X Interface
and that's the page, bestie!! π this was XtAppNextEvent(3) from X Version 11, libXt 1.3.1 β go forth and process some events, you absolute legend πβπ
π¦ where this page comes from
- alpine 3.22: libxt-doc 1.3.1-r0 Β· MIT
- alpine 3.23: libxt-doc 1.3.1-r0 Β· MIT
- alpine 3.24: libxt-doc 1.3.1-r0 Β· MIT
- arch rolling: libxt 1.3.1-1 Β· MIT AND HPND-sell-variant AND SMLNJ AND MIT-open-group AND X11
- fedora 43: libXt-devel 1.3.1-3.fc43 Β· MIT AND HPND-sell-variant AND SMLNJ AND MIT-open-group AND X11
- fedora 43: libXt-devel 1.3.1-3.fc43 Β· MIT AND HPND-sell-variant AND SMLNJ AND MIT-open-group AND X11
- fedora 44: libXt-devel 1.3.1-4.fc44 Β· MIT AND HPND-sell-variant AND SMLNJ AND MIT-open-group AND X11
- fedora 44: libXt-devel 1.3.1-4.fc44 Β· MIT AND HPND-sell-variant AND SMLNJ AND MIT-open-group AND X11
- opensuse-leap 16.0: libXt-devel 1.3.1-160000.3.2 Β· MIT
- opensuse-leap 16.0: libXt-devel 1.3.1-160000.3.2 Β· MIT
- opensuse-leap 16.0: libXt-devel 1.3.1-160000.3.2 Β· MIT
- opensuse-leap 16.0: libXt-devel 1.3.1-160000.3.2 Β· MIT
- Copyright 1993 X Consortium
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms